On 10/15/2011 03:13 PM, Kern Sibbald wrote: > 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.
Okay this is my concern, I know because I follow the trunk of sources when and what are the patch backported to 5.0.x But I'm pretty sure, their integration in distributions vary a lot. At least that's what happen. Most of the packagers are not very aware of that (missed communication, not so commited with what happen in Bacula) and are often inform by end user that a new version is here. It was like that during years with all the intermediary release before 3x trunk. I know how much efforts you put each time to get all of that published on sourceforge. > >> >> 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 And then nobody knows which real level of patching is that version Did 5.0.3-3 contain the commit I need or the packager has corrected for example an init script, and firewall rule which has nothing to do with the trunk. With all the tools (perhaps some need polishing) present already in the trunk, it's really quick to run makebacularel scripts and push those on sourceforge (or whatever website the community will use in the future) I don't mean you have to do that. I think what concern the community should be also it's responsibility. With your agreement and help of course without eating your time on something that can be delegate, which is obvious the case for those kind of intermediate release (bunch of patches or whatever). The second cool aspect on that, is having a way to be more present in "news" What's up with Bacula ? If people look, well nothing for more than one year (06 August 2010) which is not true ... It just look like. (You don't have to justify anything here okay?) So getting intermediary release ( patch level ) would keep a bit more the light on this precious project. (at least I'm convince about that) >> >> 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
