On 10/15/2011 02:05 PM, Bruno Friedmann wrote: > 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 )
Yes, exactly! One minor detail that doesn't change anything you said is that 99.9999% of the time after version 5.2.x, we will start a 5.3.x branch for development. When it is released, it could be either 5.4.0 or 7.0.0. It is highly unlikely we would go from releasing 5.2.0 directly to a 7.1.x development branch until after 7.0.0 is released. Note, one thing not documented though I have mentioned it in emails and a number of public presentations is that in the future community version will always begin with an odd number (5, 7, ...) and Enterprise versions an even number (4, 6, ...). > > 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 I am not 100% sure what you are saying, but we have pushed quite a number of patches to Branch-5.0 since Bacula 5.0.3 was released. Once we get close to a release (a few months) as is currently the case, we generally stop back porting. > > 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 ) It would not be a good idea (if that is what you are suggesting) that you put out yourself a Bacula version 5.0.4. Sometimes we start pushing patches to the 5.0 branch after releasing 5.0.3 and then we decide there is something critical or whatever and we release a 5.0.4. > > 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. As mentioned above, the best procedure is for you put out, as Red Hat, and every other vendor does when they patch an upstream project a 5.0.3-2 or 5.0.3-3, ... where the -2, ... indicates the packager's patch number (as noted in the Fedora document the exact format of the packager can be a bit more complicated). Kern > > 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. > > > ------------------------------------------------------------------------------ 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
