New release cycle; was: Re: [dev] Fwd: HEAD
Eric Rostetter
eric.rostetter at physics.utexas.edu
Sat Mar 22 01:29:39 PST 2003
Quoting Jan Schneider <jan at horde.org>:
> > Yes, and we could have released it a while back, just before we did the
> > new UI interface. That was a stable time, with lots of new features, and
> > no real problems/debates other than making a major all-encompassing
> > UI change.
>
> This just wouldn't work. If people have a good idea/patch for the code it
> won't be hold just because we perhaps will release a new version in the next
> few months.
Yes, correct. I'm suggesting holding it for at most a few days, not a
few months. Anything more than a couple weeks would of course be
silly.
> This "short time" won't happen and "release early, release often" won't work
> in this project.
Won't work? Can't work? We should try to make it work? Any reasons behind
your statement to back it up? Should we base the future on the past, or
present, or try to improve on the past/present?
> I still remember well the long and winding road we had before the last major
> releases. It took a lot of time and manpower to get them on the shelves and
> iirc the release process took a few months.
That doesn't mean we can't change things in the future.
> Don't get me wrong, I'd love to see a new release cycle but I fear that we
> don't have the ressources and discipline for this at this moment.
But could we develope the discipline, and help find or remove the need
for some of the resources?
> > Right now, I don't see it as ready... In a short while, maybe it will
> > be. What we need perhaps is for someone to jump up and down and scream
> > and shout when we hit those points where it is ready, so we can get a
> > release out at that time instead of making major changes which preclude
> > a new release coming out any time soon.
>
> The only way this might work with our current ressource at all would a
> complete feature freeze and concentration on bug fixes and stabalizing the
> new stuff for the next two or three months. Do we want to do this?
I'm not convinced of your arguments. But that aside, I'll propose another
way to do it -- make a new branch. Have the releng branches, the HEAD
branch, and another temporary branch that is, for lack of a better name, the
feature-frozen-debugging-soon-to-be-released branch... When it is
released, it is moved/renamed to the new releng_* branch. That way we can
still have the current stable branch, the current development branch, and the
soon-to-be-released branch, and they won't interfer with each other. In
a sense, this would be a "beta" branch.
Just some ideas, kind of the "devil's advocate" line of thought...
No offense to anyone intended...
--
Eric Rostetter
The Department of Physics
The University of Texas at Austin
Why get even? Get odd!
More information about the dev
mailing list