protux-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Protux-devel] Regarding Release Coordination


From: Luciano Giordana
Subject: Re: [Protux-devel] Regarding Release Coordination
Date: Wed, 3 Dec 2003 22:38:11 -0200
User-agent: KMail/1.5

I somehow had decided something like that. The only major releases will be 
0.30, 040, 050, 0.60, 0.70,0.80, 0.90 and 1.0 only (more 8 only), no more 
intermediate release, only via CVS.

But there is no need to fork CVs, althought this a good idea. The "major 
releases" are just points to expand the marketing and get a bigger user base 
so we get the feedback.

for example, next 0.30 will have the undo engine (among other things). This is 
important step and I believe it worths a major release. Also, dont worry TOO 
Much in stabilization of any relaease before 1.0. Only partial stabilization, 
just to have a good binary and expand our user base.

the 1.0 is the real  "FIRST" protux. all the releases so far are just a branch 
of unstable code.  :-)


On Wednesday 03 December 2003 05:30 pm, Remon Sijrier wrote:
> Hi all,
>
> I had some little discussion about this with Reinhard and unfortunately
> this conversation didn't go via protux-devel and I deleted those mails per
> accident. So I have to do it with my memory ;-)
>
> Most important point was this:
>
> "Do not release protux until everything is finished/tested/updated etc.."
>
> I understand this puts a high limit on development when nearing to a
> release, but it has been a month ago since 0.20.0 is out, and the website
> and docs are still _very_ out of date....
> Of course, protux is meant to in development mode til 0.50.0, but if you
> rely to much on this, it doesn't make sense to release "major" releases at
> all
>
>
> So I suggest to do it different in the future:
>
> Split CVS into "stable" and "head" This must be somehow possible. When
> nearing the next major release, fork CVS into "stable" and "HEAD", freeze
> the "stable" branch and continue development on "head". Only bugfixes will
> be excepted for the "stable" branch. (which makes it for me much easier to
> add bugfixes to a release. It's very hard for me to do it now. Also for
> other people to download the bugfixes to test it)
> Then go for testing "stable" until there are no more important bugs, and
> _after_ the docs and website has been updated, announce the new release.
>
> One of the things which happend just before the 0.20.0 release was that
> there were a bunch of features added which introduces new bugs. That's of
> course annoying and IMHO should be avoided. With the release structure
> mentioned above this will no longer happen, and also prevents the developer
> to do such things.
>
> I also prefer to have something like a "release coordinator". Although it
> may seem a bit of overstructuring the whole process, it puts of the load
> from the developers, and a release only comes when it is time....
>
>
> Thanks and RFC please.
>
> Greetings,
>
> Remon
>
>
>
> _______________________________________________
> Protux-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/protux-devel

-- 
Best Regards
--
Luciano Giordana
Free Software Developer / Musician
Project Protux : Professional Audio Tools for GNU/Linux
http://www.nongnu.org/protux




reply via email to

[Prev in Thread] Current Thread [Next in Thread]