On Thursday, 29 November 2012 at 19:53:13 UTC, deadalnix wrote:
On Thursday, 29 November 2012 at 19:30:00 UTC, H. S. Teoh wrote:
Isn't this only necessary if the new feature depends on said
breaking
changes? If not, it can be safely merged in. If it's a trivial
change
like a syntax change, the stable maintainer can simply fix it
by hand
and merge it in anyway.
New code means new bugs. This is why most project use the 3
numbers version. Eventually, if you add a new module to phobos,
people use it, and even if you don't you ends up using it
indirectly and you get the bugs.
The 3 number system is fine grained enough to do what we probably
want.
If we use 3 version numbers like this: major.minor.revision, then
Incrementing "major" indicates a major release with breaking
changes incorporated and/or new features added.
Incrementing "minor" indicates no breaking changes, no new
features, but possibly new bugs were introduced due to the the
changes that were made.
Incrementing "revision" indicates a bug fix only release.
We should also have 3 branches in principle, each corresponding
to the 3 version numbers. One for stable, which receives only
revision updates after major.minor is frozen, another for
pre-stable and also for the "stable candidate" which frozen from
new features, but uses same branch, and a 3rd for unstable, which
eventually moves to pre-stable branch.
This is more or less how Debian seems to do it.
--rt
