On Wednesday, 19 December 2012 at 06:31:04 UTC, Rob T wrote:
On Wednesday, 19 December 2012 at 01:48:49 UTC, deadalnix wrote:
I think the smart move here is to release new feature less
often, but to release more at once, and at the same time go
fast on bug fixes.
I'm not a a fan of time line based releases (snapshots), it
makes no sense to me at all other than for producing a testing
version, and even then I'm not so sure.
Why release a new stable branch every 6 mo's or whatever? Why
not release a new stable branch when there's one worth
releasing? Why not instead focus on releasing "revisions" (bug
fixes) instead, up until there's enough of something new worth
releasing as a package. New stable releases, should be major
version number increments and they should not happen very
often. Bug fixes should happen much more often, and if they are
released as new branches, then the old ones should not get
support, as it's pointless, that's what the most recent stable
release branch provides. I can see us supporting a previous
major release version, but not any of the minor bug fix
increments that appeared along the way.
Perhaps there is resistance to changing from the current
"snapshot" process which tends to produce meaningless
buggy/breaking releases, to one that is a "feature" based
release.
I can't even say if you agree or disagree with what you quote.
If we want to understand each other, it may be nice to start
using common vocabulary. In the planned process exposed on the
wiki, you'll find no branch called stable (for good reasons).
Nobody talked about doing revisions in branches, it make no
sense. Again, you should read what is written in the wiki page.
Nothing is released as new branch. I don't even understand what
it is supposed to mean. Thing are released as
.zip/.deb/.rpm/.dmg/whatever packages.
Finally, nobody is supposed to support fix, this is the other way
around : fix are what you do when a supported version has a bug.
