Developers of Sympa

[Olivier Salaün <address@concealed>]

Guillaume Rousse a écrit :
> David Verdin a écrit :
>   
> > So you concur to our doubts. We think that we must increase the rate of
> > release, so that people don't download bugs that have been patched a
> > month before. But we felt that a daily base could be too much and would
> > lead to too much versions.
> > Does anybody have a clue about when it is pertinent to release a new
> > version?
> >     
> As soon as you feel it's worth the work, such as fixing a bug for
> instance. Clearly, it's difficult to have an objective criteria here :)
>   
Our criteria for (somehow automatically) releasing new stable versions 
very often is to lower the lifetime of a stable release that includes 
already fixed bugs. As an example, there have been 73 commits (about 60 
are real code changes) in our sympa-5.3-branch branch, all this changes 
being significant bug fixes ; but we have released only 4 stable 
versions from this branch. Therefore users have been downloading the 
5.3.3 version from july 2007 until november 2007 with a couple of bugs 
that had been fixed in the SVN repository in th meanwhile. That's too 
bad we did not release a weekly version with all recent bug fixes in it.

Of course we could not afford to have a similar auto-release process on 
the development trunk because it includes more changes, including code 
design changes and new features.

> > > The second is the easyness of producing a new release. You're clearly
> > > reinventing the wheel there. If you had a correct autotools
> > > configuration, this would be just a matter of 'autoreconf && ./configure
> > > && make dist' (and even better, make 'distcheck' to automatically
> > > conduct minimal safety check against it). 
> > >       
> > The only difference I see is the name of the command called.
> > For now, producing a new release is just a matter of
> > '/usr/local/bin/tag-new-version.pl'.
> > Sure, the autotools commands are standard commands, but as the creation
> > of new versions implies an access to our servers, we are the only one
> > who will ever use these scripts.
> > Therefore I don't see the point of using them, as what's important is
> > the sequence of operations performed, not the name of the command.
> >     
> That's not the name of the command that matter, that's the correctness
> of what it does. I always have more confidence on widely used and tested
> code than on self-made solution. I don't think your solution allow
> automated testing of produced archive for instance, as 'make distcheck'
> does.
>   
Of course using standard tools (like autotools) is a better solution 
when possible, and we appreciate very much the help you are providing in 
this area. But for tools that we don't distribute, our main goal is to 
have the processes in place ; using standard tools in only a plus. We'll 
investigate in the "make distcheck" direction to find out the advantages 
of this solution.


Thanks for the feedback Guillaume.