On 09/25/2009 04:02 AM, Antonio Cunei wrote:
> The fact that the community is eager for code to be available for
> porting to won't change the fact that the code in trunk is exactly
> what it is: development code. The feedback we gather from users who
> try trunk is invaluable, but it not production code, nor code in which
> any particular feature is supposed to be complete. "Better" means
> beta: you need to wait a few more weeks.
I'd like to just throw this out in -debate to hopefully stimulate
discussion; please don't take it as my prescription for how the Scala
project ought to work:
Having multiple parallel streams of development all targeted at a single
big release is pretty common in larger commercial software projects.
One way we make it tractable is to plan for explicit milestone releases,
each of which integrates functionality that is ready for integration
tests and unlikely to break other features, but that is not necessarily
expected to be alpha quality yet. Changes should be assigned to
milestone slots based on their size/complexity/difficulty and a rough
idea of their dependencies--changes that more likely to impact other
changes (or simply needed by them) must be slotted into earlier milestones.
It's not necessary for each milestone to have its own branch, but it's
important for all the feature/module owners to have a milestone
deadline, e.g. if I know my feature is targeted for M4, and if it misses
that date, it's probably not going into the release.
Here's how I've done it in the past, with a fair degree of success, on a
moderately large (~750kloc) Java codebase.
<branch point> (or just tell everyone to keep their awesome
experimentation the hell out of trunk)
M0 progress:
Make the major structural/architectural changes that are important,
don't necessarily change functionality, but will make our lives a living
hell if we do them later in the project (major
platform/library/dependency version changes, reorganizing modules...)
M0 tag:
Sanity check, make sure everyone on the team agrees that the project
platform/structure/architecture/library versions will work for the
features they're responsible for.
M1 progress:
The most complex/important/depended-on functionality for this release
really needs to come in here. Generally speaking, in each milestone,
one or more changes are now ready to integrate, merged/committed to the
release branch (or trunk), integration problems are cleaned up,
functional tests *for features scheduled for this milestone* mostly pass.
M1 tag:
M1 features are ready for review, initial testing, criticism etc.
M2..n: (repeat)
Alpha:
All the major refactorings, bug fixes and features that are intended to
ship in this release are integrated, developer-tested and ready for
wider QA, but there are still plenty of known bugs and cut corners. Any
change that was scheduled for a milestone but has yet to attain alpha
quality is not going in the release, or the alpha can be postponed (and
another milestone explicitly added) for changes that are deemed
important enough to slip the release.
Beta:
Basically what you'd expect. All changes integrated, no known bugs that
don't have known workarounds...
At my last job we also had sub-milestone tags we called M1a, M1b etc.
When the developers honestly believed the M1 functionality was ready
we'd tag M1a, then QA would laugh at us and we'd ship zero (*cough*) or
more subsequent sub-milestones roughly once a week until QA signed off
on the final M1x and we'd finally move on to the next milestone.
-0xe1a
