Re: [Nano-devel] nano-2.4.3pre1 ready for testing

[Mike Frysinger]

On 17 Nov 2015 18:02, Benno Schulenberg wrote:
> Having an even and an uneven series, a stable one and a development
> one, is old-fashioned.  The idea today is: quick releases.  Firefox
> churns out a release every six weeks, the kernel every two months.
> I don't know the cadence of Chrome, but it must be something similar.

your examples don't jive with your position ;).  all those projects have stable
trees which are actively maintained.  but they have the people to cover it.

as for Chrome, it's even more expansive: they branch master every ~6 weeks,
but then they have a waterfall of releases with independent testing:
  R43: stable channel (what most people see)
  R44: beta channel (a good # of users)
  R45: dev channel (mostly developers)
  master: canary channel (here there be dragons)
as bugs are logged, they get fixed/backported to all the active versions.
once crash rates are down and stability looks good, then a version gets
moved up:
  R43 -> retired
  R44: beta -> stable
  R45: dev -> beta
  master -> branched into R46 -> dev
but each of those steps are independent, so you might have a single version
in both beta & dev while major stability issues are fixed in master.

git makes branches cheap, so i don't see an issue with creating one for each
major release and then just cherry picking fixes as reported into it.  so we
would have a 2.4 branch, and only bug fixes would go in (crashes and such).
after a certain amount of time (a month?) forget about it and just move to
the next major version/branch.  i don't think long-lived stable branches are
that useful here.
-mike

signature.asc
Description: Digital signature