On 10/15/2011 12:31 PM, Laurent Papier wrote: > On Fri, 14 Oct 2011 14:54:44 +0200 > Bruno Friedmann <br...@ioda-net.ch> wrote: > >> Dear Developers >> >> This proposal doesn't have to by applied now, so it's mainly a reflection >> for the next run >> 5.3dev 5.4x >> >> Most of the package system (rpm / apt) and associated tools doesn't play >> well with beta rc string in number >> making it always complicated for no good reasons 5.2.0rc2 is > than 5.2.0 >> (work if we start at 5.2.1) > > Hi, > Fedora have a detailed solution for this problem > (http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Release_Tag). Maybe > it is specific to rpm package but the solution is easy to use and provide a > smooth upgrade path from rc release to stable release. Thanks to the pointer, of that one, I've loose it .. > > For example, my personal package for 5.2.0rc1 is bacula-5.2.0-0.1.rc1.fc14. > 0.1.rc1.fc14 is the release tag. The 5.2.0 stable release will have a 1.fc4 > tag which is greater than 0.1.rc1.fc4. > Ok that could work too for us.
> Any debian/ubuntu packager guru here ? > I would like to invent too gentoo, slackware, solaris, Mac OSX and any other plateform we build on to give at least an opinion. >> On what I see, most big project now use this numbering politics >> alpha stage start with 5.1.6x to 5.1.79 >> beta are mostly in the range 5.1.80 to 5.1.89 >> rc are in 5.1.90 - 5.1.99 Ok drop that way, not appropriate here (was an idea, and doesn't cost so much to throw it) Thanks Kern for your opinion on that express in your message. > > Because there is not a single rule for every project all around the net, I > personally found this a little bit confusing. > If you are very familiar with the project how to you know that > bacula-5.1.64-1.rpm is an alpha release and bacula-5.1.38-3.rpm is a stable > one ? > Because bacula use odd and even numbers too ... and only even are stables one. a 5.1 can't be anything else than a developpement release. 5.2. a stable one, next is devel is 5.3 (or 7.1) etc... And to be clear entreprise is 4.0 (thanks to Kern to state that one more time : his answer come on -ml ) And that's our packager's role to not push an alpha or beta version in a stable repository too :D Bacula devs actually for example in the 5.0x branches didn't push any more an intermediate bug fix release So as packagers we will have several choices, make it clearly that a new release 5.0.4 which contain all patches at a moment in time and re-release the tar.gz|bz2 (which can be a coordination with Bacula upstream git maintainers ) Or bundle patches by patches what happen in git ... and create divergence between distributions. Increasing complexity in support for the community. Then a end-user looking for a fix as to read the rpm changes or digg in the how it has been made to be sure the patch is inside. The most important here is trying to get a kinda of inter-cross-distribution-operating-system agreement on how we want to handle and manage the community tree, and the integration of patches in binaries/sources the community can offer for bacula end users. Which is our primary objective in my opinion. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Ambassador GPG KEY : D5C9B751C4653227 irc: tigerfoot ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
