[rabbitmq-discuss] What does "beta" mean for RabbitMQ?
Alexis Richardson
alexis.richardson at gmail.com
Wed Oct 21 20:22:52 BST 2009
Uwe
We are still discussing this. The current proposal we are looking at,
is to radically simplify the release status descriptions. We may
provide an orthogonal statement concerning 'which version to use' that
politely explains that each release - while QAd to a high standard -
is still ipso facto novel, in order to ward conservative adopters off
being among the very first to use it.
alexis
On Tue, Oct 20, 2009 at 8:16 AM, Uwe Kubosch <uwe at datek.no> wrote:
> Hi Alexis!
> Thank you for the quick reply.
> My initial thoughts:
> 'beta' implies 'unfinished' and 'unstable'
> 'release candidate' better reflects your description of the status of the
> release.
> Make an event of declaring a release "final", and announce this event in the
> initial release announcement. Something like:
> "This release has 'release candidate' status pending user feedback and will
> be declared as 'final' in 4 weeks unless major bugs are detected. We
> recommend that developers, testers and non-critical systems using earlier
> versions of RabbitMQ upgrade to this latest release."
> Then 4 weeks later: "RabbitMQ 1.8.0 declared final! The package has been
> downloaded 4 million times and we have received positive feedback from our
> users. No major bugs have been reported. We recommend that all users of
> earlier versions of RabbitMQ upgrade to this latest release."
> If you detect major bugs, you do not announce the 'final' status. You
> should announce the bug instead and include when the bug is expected to
> fixed. Something like "A major bug was reported and will be fixed in the
> 1.9.0 release.
> Personally I like patch level releases to quickly fix bugs to make a minor
> release branch stable, but i realize it takes less organization and effort
> to fix the bug in the next minor release.
> I also like packaging the release candidate with an 'rc1' in the version
> string like rabbitmq-server-1.8.0rc1, but that requires repackaging when the
> final release is out, so keeping the same package but declaring it stable
> after a while saves the extra packaging.
> Really, any solution that keeps me from browsing around looking for the
> 'stable' release is good :)
>
> Uwe
>
>
> On Oct 18, 2009, at 11:16 PM, Alexis Richardson wrote:
>
> Uwe
>
> Great questions. We seek advice on how to make this clearer. Please
> take a look at this first, and let us know what you think:
>
> http://www.trapexit.org/forum/viewtopic.php?p=49591&sid=20d06e54360b9122cd625eb6e459cfeb
>
> alexis
>
>
> On Sun, Oct 18, 2009 at 10:00 PM, Uwe Kubosch <uwe at datek.no> wrote:
>
> Hi all!
>
> Here are a few FAQs for you:
>
> Why are all the releases of RabiitMQ "beta"?
>
> What does "beta" mean in this context?
>
> Should I NOT use RabbitMQ in a production environment?
>
> What are the criteria for a "final" release of RabbitMQ?
>
> Feel free to answer directly or post a link :) I have read the FAQs and
>
> other documentation, and RabbitMQ seems mature from user reports, but the
>
> official status of "beta" bothers me, and I am struggling to understand what
>
> it means.
>
> Any reply is appreciated.
>
> With kind regards,
>
> Uwe Kubosch
>
> Datek Wireless AS
>
> Norway
>
> _______________________________________________
>
> rabbitmq-discuss mailing list
>
> rabbitmq-discuss at lists.rabbitmq.com
>
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>
More information about the rabbitmq-discuss
mailing list