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

[Chris Allegretta]

This is sort of where my brain was: I'm very used to having prod and
beta at minimum versions of software as a consumer  of software, but
in my professional life there has definitely been a move, as Benno
points out, to having release live very close to trunk all the time.

We could as a compromise do something like: move the 'stability
indicator' in x.y.z from the y value to the z, and just say every
other release (i.e. the 'evens' excepting .0 of course) we'll focus on
bugs from user reports.  Not that new features can't be in those
releases at all, just that we'll focus on bug fixes primarily.


On Thu, Nov 19, 2015 at 4:57 PM, Mike Frysinger <address@hidden> wrote:
> 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
>
> _______________________________________________
> Nano-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/nano-devel
>