8 Feb
2008
8 Feb
'08
5:39 p.m.
Hi Henning,
Henning Westerholt wrote:
On Friday 08 February 2008, Bogdan-Andrei Iancu
wrote:
I see some issues in this approach.
But firstly, I agree that more often minor releases will be good.
Now, the issues I mentioned:
I see no advantage of pushing the fixes via minor release. A minor
release is just a TAG and a source tarball - none of this help, as you
still have to go compile stuff locally (sources from tarballs or from
SVN, it's the same).
We cannot do minor release for each fix - there may be highly critical,
critical, medium or low as severity and we will end up with a release at
each day :)
I thing people are using branches and not tags from SVN - the branch
simply gives you the latest version from a major release, and as there
are only fixes, there are no reason not to update (1.2.0 -> 1.2.1 ->
1.2.2 -> 1.2.3). So, a simple SVN update solves the problem in most of
the cases.
Also we need to take into consideration the fact that there are people
using "blended" openser, so they can update only via patches ;)
Whatever we do, we need to accept that developers will never put very
explanatory logs into commits (developers speaks their own language when
comes to code, language which is not understandable by users) - like for
cars - technicians use their language which is not supposed to be
understood by driver/client ;)
Going back to my original idea - what I wanted to provide is:
- a fast way to provide detailed, handy, end-user (human) readable,
reports on the latest fixes, as soon as possible.
- provide notes for all fixes (not only the one we really decide are
important enough to trigger a minor release)
- interface between the developer logs and understandable report for
the users
- indication about the possible ways to update (rev number, patches,
etc)
- this doesn't exclude your idea of minor releases for major fixes.
Regards,
Bogdan
[..]
Many project have lists where you can subscribe in order to get
notification for critical bug or security fixes. Currently, for openser,
if you are not subscribed on devel list and if you are not "good" enough
in "decrypting" the commit logs, you may miss important fixes you may
want to update.
I think is our duty as project to inform the users about the discovered
flows in the stable versions. My suggestion is to create a new mailing
list where, who is interested, will receive notifications when something
critical was fixed in the stable versions of openser.
[..]
Hi Bogdan,
good points. Such a list would be surely a good thing. But i don't think this
is exactly what we need. If somebody choose to run a openser version from the
stable branch, he must monitor the devel list for importantant changes in
this branch. This could be easily achieved with some filtering. If there are
understanding problems with svn commit messages, we should improve them.
Remaining questions could be easily be resolved on the devel list.
But distributions and many users don't use the stable branch as base for their
usage, the rely on stable releases.
So if a really critical fix is merged into the stable branch, e.g. a security
fix, then we should immediately release a new minor release that includes
this fix. Otherwise the user which don't have the knowledge or the time to
run from the stable branch will be left in the cold.
So, my suggestions are:
- implement a regular release schedule for minor releases, e.g. every 2 months
- release immediately for _really_ critical fixes
- add a new list, called "announce" for announcements for new releases
This policy is implemented from many successful other projects. This way
people running stable or from the branch know that there was a cricital fix,
and that they should update.