On 4/8/02 7:01 PM, "Skip Montanaro" <skip@pobox.com> wrote:
>
> Chris> The double-branch option is easier, and I know that when the
> Chris> FreeBSD group releases 4.5-RELEASE, it's been tested and solid,
> Chris> and will be supported by bug fixes for some period of time. They
> Chris> have only just recently stopped issue security patches for the
> Chris> 2.x tree.
>
> Is *-RELEASE a third branch, or is it what falls out the end of the *-STABLE
> pipe?
RELEASE is actually just a tag on the RELENG branch of the tree. For
example, FreeBSD has the following branches in CVS for 4.x:
RELENG_4
RELENG_4_3
RELENG_4_4
RELENG_4_5
On those, there are tags for the releases:
RELENG_4_0_0_RELEASE
RELENG_4_1_0_RELEASE
RELENG_4_2_0_RELEASE
RELENG_4_3_0_RELEASE
And so on. This does create a more complex CVS environment than Python uses
(and probably similar to what we used at Zope). This is not a bad thing, as
it allows you to control things more carefully, but requires more CVS
knowledge on the part of people involved.
The following section of the handbook explains in some more detail about how
the two branches progress through their life cycle:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.htm
l
BTW, as to libraries and /F's comments... I think the library modules should
always have to lag at least one release behind the interpreter. Maybe 2?
This gives a couple of things:
- No introducing weird problems in the library to compound compatibility
issues
- Iron out new features/changes by letting those people actually using
them benefit/feel the pain, before we make the general populace deal.
Again, I think stating what "policy" is about support for older releases is
solves a HUGE amount of the problem. And probably a bigger percentage than
a numbering scheme ever could.
Chris
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4