3 ms·
To mention the obvious, this won't work in all circumstances. For some technologies, you will want to branch and release (e.g.) new features in the 2.0 branch,
by mkopinsky 15y ago
To mention the obvious, this won't work in all circumstances. For some technologies, you will want to branch and release (e.g.) new features in the 2.0 branch, and bugfixes in the 2.6 branch. If I'm on 2.6, I can plan to permanently stay up to date with the most recent 2.6.x release, without worrying about new features messing me up.
- latitude 15y agoYep, sure thing. This is more in a context of end-user products that tends to have linear release stream and shorter release cycles.
- yuliyp 15y agoBut even if you have a linear release stream, you've probably got branching going on internally once your product gets to have a significant installed base (i.e. you fork a release branch to let your main-line development continue while you polish the release up before shipping it). At this point, you have builds going on in two branches, and thus tracking the version numbers when you get issues reported becomes critical ("are you using release 37 installed 2 days ago or today?").
- latitude 15y agoWell, the point being is that users shouldn't really be exposed to the details of internal branching. It is perfectly fine to use hierarchical versions internally, but they should be mapped to something simpler for the public releases. A one-to-one mapping, there should be no such thing as two different #37 releases.
- yuliyp 15y agoAh, I guess you then run into some blurring when you get to external beta testers and partners, or if you're developing an open-source product. But if you've got a closed-source product that you can manage the external releases to a single stream, then yeah, you can go with simpler public revision numbers.