[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Release proposal
From: |
Jan-Henrik Haukeland |
Subject: |
Release proposal |
Date: |
15 Sep 2002 21:27:03 +0200 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Civil Service) |
Hi guys
We have around 30 persons on the monit general mailing list, after the
beta was announced this week only two persons actually downloaded the
beta, one was Thomas and the other (I guess) Christian. In other words
we do not get very much feedback from the users on the list.
I suggest a "new" or actually the old release strategy, based on the
assumption that we have to do all the work ourself, including testing.
So, when we, that is the project committers, have tested a monit
release candidate for some time without any incident we simply release
the new candidate as a release (not a beta release). Traditionally
there has been few, if any bugs in previous releases of monit and I
feel that the quality of the current code is good if not better.
Also, traditionally we get more feedback and more users when we do a
new release, since a release includes posting to freshmeat.net. To
release often is also the Linux strategy, it drives the user feedback,
development work and general interest for the product.
As usual, in the "unlikely" case there are bugs we can create a new
bugfix release pretty fast.
What I'm argumenting for here is that we release the current code as
monit 3.0 tomorrow (16. September) or the next day. A release proposal
should be voted on and this is my;
+1
--
Jan-Henrik Haukeland
- Release proposal,
Jan-Henrik Haukeland <=
- Re: Release proposal, rory, 2002/09/16
- Re: Release proposal, Jan-Henrik Haukeland, 2002/09/16
- Re: Release proposal, Christian Hopp, 2002/09/16
- Re: Release proposal, Jan-Henrik Haukeland, 2002/09/16
- Re: Release proposal, Christian Hopp, 2002/09/16
- RE: Release proposal, Jan-Henrik Haukeland, 2002/09/16
- branches, Rory Toma, 2002/09/16