52 ms·

For React Native we do ~monthly releases and just increase by 1 each time. It’s a train model this way people know when their changes will get released. I guess

by vjeux 5y ago

For React Native we do ~monthly releases and just increase by 1 each time. It’s a train model this way people know when their changes will get released. I guess we should consider bumping to 1.x at some point and keep going :)

Heliosmaster 5y ago
why not switch to a year-month then, if the release process is already time-based?
- emteycz 5y ago
  1. cost (and risks) of switching - not just for the project itself, but across the ecosystem and all the millions of users 2. what if you need multiple releases in a month, in a day? 3. if it works, don't touch it
  - nick__m 5y ago
    i dont have awnsers for 1 and 3 but reagarding 2 the format YYYYMMDD.NN allow you to have 100 releases a day...
nicoburns 5y ago
Monthly? There were 3 releases in 2019, 2 in 2020, 2 so far in 2021 if you count the imminent 0.65 release. I guess maybe it's monthly if you count the patch releases? But you can't really claim to "just increase the number by 1 each time" when you have two separate numbers which get incremented for different reasons.
- vjeux 5y ago
  I haven’t worked on React Native for many years now… looks like it has slowed down! It was monthly in the first few years.
jrochkind1 5y ago
Do you have any policies around backwards compatibility? Is there any way to know if a given release has intended backwards-breaking changes or not?
dathinab 5y ago
Skip 1.0 and 2.0 to brake people's expecting. Like at some point just e.g. move from 0.69.0 to some arbitrary number like 7.0.0 or even 70.0.0.
- simiones 5y ago
  Java did that, right? From Java 1.4 to Java 5. Also, at $WORK we have three separate but related products, each with separate version numbers that we jumped at some point to reach the same value across all 3. One of the products jumped from 3.x to 9.0 I believe.
  - _tom_ 5y ago
    Java 5 was still v1.5, except for marketing, iirc. The 1.x versions persisted internally for a few releases.
  - dathinab 5y ago
    Java moved from 1.4 to 1.5 and just stopped displaying the 1. The reason was that they committed to never to any "major braking change" i.e. that there would never be a version 2. At the same time the backwards compatibility guarantees didn't work always as good as some people liked so they decided to move from semver to something which is like "only do minor releases, but sometimes imperfect making them somewhat major releases but also somewhat not". What I advocated for differs in that I want to keep semver. So when you move from e.g. 0.32.0 to 32.0.0 you still would only inc minor version for non braking changes and the patch version for patches. Through this means that you now can denote path updates, as in 0.32 the minor updates are like major updates and the patch updates are like minor updates. This can be especially useful when development release speed slows down and you want to make a new release with e.g. just fixing some API docs or just non API exposed bug fixes.
    - magic_quotes 5y ago
      Java / OpenJDK never used semver in the first place. Also, large projects like Java have entire layers of different APIs, whose compatibility guaranties can't really be described with a single number, no matter what versioning scheme they use.

by vjeux 5y ago

Heliosmaster 5y ago

why not switch to a year-month then, if the release process is already time-based?

emteycz 5y ago
1. cost (and risks) of switching - not just for the project itself, but across the ecosystem and all the millions of users 2. what if you need multiple releases in a month, in a day? 3. if it works, don't touch it
- nick__m 5y ago
  i dont have awnsers for 1 and 3 but reagarding 2 the format YYYYMMDD.NN allow you to have 100 releases a day...

nicoburns 5y ago

Monthly? There were 3 releases in 2019, 2 in 2020, 2 so far in 2021 if you count the imminent 0.65 release. I guess maybe it's monthly if you count the patch releases? But you can't really claim to "just increase the number by 1 each time" when you have two separate numbers which get incremented for different reasons.

vjeux 5y ago
I haven’t worked on React Native for many years now… looks like it has slowed down! It was monthly in the first few years.

jrochkind1 5y ago

Do you have any policies around backwards compatibility? Is there any way to know if a given release has intended backwards-breaking changes or not?

dathinab 5y ago

Skip 1.0 and 2.0 to brake people's expecting. Like at some point just e.g. move from 0.69.0 to some arbitrary number like 7.0.0 or even 70.0.0.

simiones 5y ago
Java did that, right? From Java 1.4 to Java 5. Also, at $WORK we have three separate but related products, each with separate version numbers that we jumped at some point to reach the same value across all 3. One of the products jumped from 3.x to 9.0 I believe.
- _tom_ 5y ago
  Java 5 was still v1.5, except for marketing, iirc. The 1.x versions persisted internally for a few releases.
- dathinab 5y ago
  Java moved from 1.4 to 1.5 and just stopped displaying the 1. The reason was that they committed to never to any "major braking change" i.e. that there would never be a version 2. At the same time the backwards compatibility guarantees didn't work always as good as some people liked so they decided to move from semver to something which is like "only do minor releases, but sometimes imperfect making them somewhat major releases but also somewhat not". What I advocated for differs in that I want to keep semver. So when you move from e.g. 0.32.0 to 32.0.0 you still would only inc minor version for non braking changes and the patch version for patches. Through this means that you now can denote path updates, as in 0.32 the minor updates are like major updates and the patch updates are like minor updates. This can be especially useful when development release speed slows down and you want to make a new release with e.g. just fixing some API docs or just non API exposed bug fixes.
  - magic_quotes 5y ago
    Java / OpenJDK never used semver in the first place. Also, large projects like Java have entire layers of different APIs, whose compatibility guaranties can't really be described with a single number, no matter what versioning scheme they use.