Re: [Bacula-devel] [open discussion] changing the way we use version.h (for next run)

[Kern S. <ke...@si...>]

On 10/15/2011 04:24 PM, Bruno Friedmann wrote:
> 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...@io...>   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)

We put out new released "patch level" whenever we consider something 
critical needs to get into
users hands.  When we fix bugs, we push those bugs to the git repo (on 
bacula.org we no longer
use sourceforge -- too slow and they are not "open" because they do not 
permit countries such
as Cuba to download).

If the community would like to do the testing necessary to put out
other intermediate releases, that is OK with us -- we may need to find a 
different release area to
avoid confusion, but be warned, if one does not carefully test one gets 
broken code in the hands of users.

There has not been as much activity on Bacula as in the past because I 
have been tied up
with administrative work getting Bacula Systems over the hump so that it 
can run itself.  I
believe as of yesterday, we are there, which means that instead of 
having 5% of my time
for programming, I expect to have 95% of my time for programming 
Bacula.  Just the same,
Eric Bollengier has been programming full-time (at Bacula Systems 
expense) and he has been integrating
all the good patches we have received so the project has not been stalled.

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.
>>>
>
>