Hal Murray <hmur...@megapathdsl.net>:
> >From devel/hacking.txt
> > When the minor number is even, it refers to a "stable" release, and when the
> > minor number is odd, it refers to a "development" release. New releases on
> > "stable" are generally bugfixes that are backported from it's matching
> > "development".
In full:
>When the minor number is even, it refers to a "stable" release, and
>when the minor number is odd, it refers to a "development" release.
>New releases on "stable" are generally bugfixes that are backported
>from it's matching "development".
>
>When a new stable release happens, that also results in the creation
>of a new development release. For example, the currently hypothetical
>future release of "1.14.0" will also cause the release of an identical
>"1.15.0".
>
>The first public release is version 0.9.0, and will drive to 1.0.0.
>When 1.0.0 is released, that will also create an identical 1.1.0.
OK, what I've just done is compatible with that poliocy if we choose
to retain it.
That text is quite old. I had forgotten it.
I have become opposed to forking stable releases for the same reasons
Linus abandoned the practice for kernel development years ago. That is,
the practical friction of cherry picking and synchronizing devel and
stable branches is a net drag on the code quality of both.
Whoever wrote that text: if you think it's still a good idea, let's
have that argument.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
