DragonFly kernel List (threaded) for 2003-11
Re: HEADS UP: Name change committed
:I belive that having a security maintained branch is quite worth it
:and should be considered. Once you announce a release, which is -
:hopefully - rock stable and well crafted, users will want to get this
:release with security fixes until you announce the next one. To
:maintain security fixes a branch is (IMO) the easiest way.
:Think of all the confuses you will run into when you find something
:security related in the third revision (since release) of some API.
:You will have to alter the tag for quite a few files in order to make
:the fix available to users. This will look strange to the average user
:and might distract from DragonFly. The normal sysadmin wants to
:understand a security update in whole.
: Max mailto:max@xxxxxxxxxxxxxx
This is very true. Still, it does not necessarily mean that one
has to branch the primary release. That is, instead of branch before
the release as FreeBSD does we could instead put the release tag on the
root branch. This leaves open the possibility of simply slipping
the tags for security fixes, snafus, and minor fixups that occur just
after a release rather then having to do multiple commits. One could
branch, say, 30 days after the release.
I think that would make developers jobs a lot easier because the vast
majority of minor fixes and adjustments will not have any other comitted
cruft in between the release tag and the fix.