> I like the ISC's release methods. The do -rc's (-pre's would be fine for
> the kernel as it is already established), each -rc fixes problems found
> with the previous. When an -rc has been out long enough with no more bug
> reports they release that code, WITHOUT changes.
Hi,
I am neither a vendor nor maintainer nor a great kernel hacker but I
think you all miss at least one point (what I for sure do too):
The problem is that you kernel hackers out there fetch the pre stuff
and test it that others run test cycles on them ... . But the
lot of people out there will never fetch anything else than
a "release" ; no -pre no -rc no -ac no whatever prefix or suffix.
You will not get them just because somebody 's changing the name
to something else.
Make your test periods longer. If there are no real serious bug in the
pre let the pre live for a week or 2 or even longer. Who cares ? We are in
'stable' branch at the moment! At some (early) point of pre-releases
stop accepting any further features and if the -pre gets real close to being
fine announce that it'll be the last one, make a note to the changelog,
wait another week for seriuos bufixes and then release the tarballs
(or if any have one more pre).
There are for sure some points that there should be better no
more different naming conventions: hpa will surely have to hack up more
scripts, things might get inconsistent between different stable/dev.
versions, we already have the -<some letter> releases for other kernel
hacker's releases like -aa -ac, ... and so on...
But if you really decide on another suffix my vote would be -rc 'cause
it's the most common one (perhaps linus then will use it in the future
too ?)
And always keep in mind: another new 'release' is nothing else than
another 'release candidate' to the next version with hopefully less
bugs more stability (and sometimes more features ;)
just my 5 cents
-- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/