Hey,
We've been mostly following http://semver.org/ for our new components, which is great. One thing we have however not been doing well is bumping to 1.0 at the appropriate time.
Major version zero (0.y.z) is for initial development. Anything may change
at any time. The public API should not be considered stable.
In other words, y denotes a breaking change, and z does not. This is shifted from the "normal" x.y.z, where x>0, in which case all breaking changes result in increment of x, feature additions result in increment of y and fixes of z. Hence if we wrongly stick around at 0.y.z, than we are also wrongly using the rest of the numbering at that point.
So when should the bump to 1.0 happen?
Version 1.0.0 defines the public API. The way in which the version number
is incremented after this release is dependent on this public API and how it changes.
How should I deal with revisions in the 0.y.z initial development phase?
The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release. How do I know when to release 1.0.0?
If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you're worrying a lot about backwards compatibility, you should probably already be 1.0.0. Doesn't this discourage rapid development and fast iteration?
Major version zero is all about rapid development. If you're changing the API every day you should either still be in version 0.y.z or on a separate development branch working on the next major version.
Most of our components are used in production and have a relatively stable API, yet they still have a version in the 0.y.z format. Let's pay more attention to this for our new components, so they don't end up in the same situation. For the existing ones we can increment the first number rather than the second one the next instance where we would otherwise increment the second one.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 --
I can tell that DataValuesJavascript and ValueView are not yet ready for a 1.0. Otherwise that would have happened. I don't know about the other components.
Cheers, tobi On Feb 24, 2014 8:42 PM, "Jeroen De Dauw" jeroendedauw@gmail.com wrote:
Hey,
We've been mostly following http://semver.org/ for our new components, which is great. One thing we have however not been doing well is bumping to 1.0 at the appropriate time.
Major version zero (0.y.z) is for initial development. Anything may change
at any time. The public API should not be considered stable.
In other words, y denotes a breaking change, and z does not. This is shifted from the "normal" x.y.z, where x>0, in which case all breaking changes result in increment of x, feature additions result in increment of y and fixes of z. Hence if we wrongly stick around at 0.y.z, than we are also wrongly using the rest of the numbering at that point.
So when should the bump to 1.0 happen?
Version 1.0.0 defines the public API. The way in which the version number
is incremented after this release is dependent on this public API and how it changes.
How should I deal with revisions in the 0.y.z initial development phase?
The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release. How do I know when to release 1.0.0?
If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you're worrying a lot about backwards compatibility, you should probably already be 1.0.0. Doesn't this discourage rapid development and fast iteration?
Major version zero is all about rapid development. If you're changing the API every day you should either still be in version 0.y.z or on a separate development branch working on the next major version.
Most of our components are used in production and have a relatively stable API, yet they still have a version in the 0.y.z format. Let's pay more attention to this for our new components, so they don't end up in the same situation. For the existing ones we can increment the first number rather than the second one the next instance where we would otherwise increment the second one.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. ~=[,,_,,]:3 --
Wikidata-tech mailing list Wikidata-tech@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
wikidata-tech@lists.wikimedia.org