search

scalajs-react-interface / sri

Apache License 2.0
151 stars 8 forks source link

Should we move towards Semantic Versioning? #16

Open frgomes opened 6 years ago

frgomes commented 6 years ago

Discussion

The article below discusses lots of aspects of Semantic Versioning. From the perspective of automation, it seems clear to me that it's the way to go: there are several libraries which implement the tenets involved in this matter. However, from the human perspective, the matter is debatable. The section I point out in the link below discusses some of these human factors. https://en.wikipedia.org/wiki/Software_versioning#Dropping_the_most_significant_element

The arcle below can be seen as a detailed study of the human factors pointed above. It's worth reading in full. http://dafoster.net/articles/2015/03/14/semantic-versioning-vs-romantic-versioning/

frgomes commented 6 years ago

I vote for semantic versioning.

The only argument I see in favor of other schemes is basically marketing. Let's suppose that we release every 6 months. Let's say that next release is 2008.10. If that is the case, nothing prevents us from creating a metapackage which unites all concrete packages, whatever versions they are. This way, we keep semantic versioning, which is good for computers, whilst we expose some YYYY.MM, which is good for humans.

virtualirfan commented 6 years ago

+1. I've been meaning to discuss this with folks for months. I agree that we should move past date versions and switch to semver.

There are some practical issues to discuss through. For some repos, it might make sense to follow react-js and react-native major/minor versioning. We could match the relevant repos to the versions of react they support.

Could that sort of a scheme help users match up the react versions with sri.

frgomes commented 6 years ago

Let's suppose that we have several repositories, like ios, android, web, etc... which is really the case at the moment. Each repository has it's own, independent, versioning.

Now let's suppose that a certain repository should is in transition from react-native X to Y. We would like to release something in 2018.10 which supports X and Y, and we are working on a distinct release candidates for X and Y, I mean: X is at RC3 and Y is at RC1.

So, nothing prevents the following scenario, where we are working on both X and Y at the same time, for multiple repositories:

Then we have a metapackage (possibly provided by repository sri) which contains two branches:

This way:

  1. Romantic versioning (sort of!) for the entire suite: users know that something is going to be released at 2018.10. Hot fixes to 2018.10 are numbered like 2018.10.1, 2018.10.2, etc. This is not really romantic versioning, but looks like... sort of.
  2. Semantic versioning per package, not concerning about release dates and/or marketing concerns and/or whatever determines when things are released.
  3. Identification of react-native: it's the X or Y in the version.
  4. Nothing prevents from adding react-js to this equation. The same way you can have X and Y for one purpose, you could have A and B for another purpose. Just add more elements after the 3 groups of digits of the version.

According to http://semver.org, whatever follows the 3 groups of digits is user defined.