mysql-proxy-discuss team mailing list archive

[nick loeve <trickie@xxxxxxxxx>]

Hi!

On Fri, Feb 20, 2009 at 5:44 PM, Kay Röpke <Kay.Roepke@xxxxxxx> wrote:
>
> The actual releases we do are then tracked as "releases" (in the Launchpad
> terminology) in the "series". For 0.7 the first one will be 0.7.0.
> 0.7.1 would be a bugfix release of whatever we find in 0.7, after it's
> released, and those fixes would most likely be backports from 0.8.
>
> There's one milestone, 0.8.0a1 currently only tracking the blueprint for the
> network-io stuff. this will expand as we put in more blueprints in there.
> The 0.7.0 release I probably won't mess with right now, but after it's out
> the door, I'd like to do more incremental "releases", namely alpha, beta,
> RCs "subreleases".
> Confused yet? I am.
>
> Essentially what I'm proposing is this:
> MySQL Proxy as a whole is labelled "alpha".
> Nevertheless I'd like to have more frequent source and binary releases of
> the steps leading towards a 0.x release, as they tend to not be all that
> often. (I'm working on setting up an automatic build environment for this
> here.)
> We've noticed that in order to get more people to actually give it a shot
> it's helpful to have binaries.
> So in order to achieve that goal, I would like to build binaries a couple of
> times even for interim 0.x.0 releases, that's what that little "a1" suffix
> on 0.8.0a1 means. I guess I could've labelled it "rc1", but that's really
> just a name.
>
> Thoughts anyone?

I like the idea of major and minor releases, especially if they are
based on small incremental changes in order to make them somewhat
timely.

I don't think you need to have the overhead of different alpha, beta,
RCs "subreleases". If you have daily/weekly/etc automatic tagged
tarballs/builds then they can play a similar role, and it can be less
confusing.

I personally don't need the binaries, but that sounds like a good idea.

My 2 cents.

Cheers

-- 
Nick Loeve