Nicola Ken Barozzi wrote:
Tim Williams wrote:
This, however, is quite a committment. While I'm for a usable trunk,
extending that though to a "releasable trunk" is more committment than
I'd want. Maybe I'm reading too much into it but claiming that at any
given moment the trunk is [apache] release quality is bold.
Ok, probably the wording is too strong.
Yes, I would prefer to think of it as trunk is always "release
candidate" releasable. Meaning us devs would use it in production, so
adventurous users should be able to as well.
We do a pretty good job of fixing users problems as they emerge. Looking
at our user lists we have a number of active devs there and an
increasing number of users helping users. I think we are strong enough
to support milestone releases.
This, I believe, would be as close as we can reasonably get to "always
releasable". We should consider making this a part of our release
process. That is, once someone says "I think trunk is ready for a new
release" we should consider making an RC release immediately. We should
make announcements about this on our mail lists, but not in the wider
community.
Once we have an RC built we only allow bug fixes in trunk, new features
are developer in a branch. Subsequent RC's for that release should be
made every couple of weeks. Once we have a couple of weeks with no bug
fixes we release.
Remember that plugins can have a separate release cycle. So only work on
core need move to a branch.
Furthremore, these branches should merge whenever possible between them
in a single branch so that they can be coded together, and get merged
with the trunk only when all developer-known bugs are fixed.
I understand that there will inevitably be dependencies between
branches but I don't care for merging branches into a single branch
(btw, wouldn't that ultimately become the defacto dev trunk?).
There should not be dependencies between branches. If there is, then it
should merge in a single branch.
But this will prevent complete features being merged with trunk because
incomplete features are brought into the branch. All that will happen
there is that the branch will get into the state that trunk was in
before the 0.7 release and we will split our devs between creating new
features in the branch and maintaining trunk (not necessarily a bad
thing, but do we have enough devs for this?)
This will also make it easier for us to release often, and to learn to
make smaller reversible changes rather than big ones that are hard to
understand by other developers and users.
Let me know what you think.
I guess the summary is that this sounds like an "Always-Branch" system
as opposed to the more pragmatic "Branch-When-Needed system" and that
seems overly rigid for little return. In other words, I doubt that a
lot of folks are able to run a trunk in a production environment and
so burdening yourselves with the overhead of maintaining a trunk in a
"releasable state" for what would amount to a handful of folks that
could use it (and likely already have svn loaded anyway) doesn't seem
worth it.
I am one of those, and I think that most Forrest developers are. If we
have at least a couple of others willing to use it, we're set.
A number of us devs appear to use trunk in production environments too
(and at least one of us is using locationmap in a production as well).
We can do so because we know the workarounds for the problems that
exist. In addition, as I noted above, we are doing a superb community
job of supporting our users. I think we can really capitalise on that at
this point, just as long as trunk is not chock full of workarounds.
In other words, I am +1 for an "always RC quality" or an "always beta
quality" (as Nicola said in another reply) trunk. I am also +1 for
"alpha" quality branches where necessary.
Ross
