On Tue, 25 Oct 2005, John Casey wrote: I'll throw in some more coins here.
> | - having a 2.1 trunk and 2.0.1 branch (or vice versa, or neither) > > I'm +1 for 2.1 as trunk, and 2.0.x maintenance branch (with that name, > and tags for 2.0.1, etc.). I think this makes the most sense, and will > lead to a stable SCM structure, which might be good to avoid the need > for constant svn relocates... +1 too, except maybe just use a 2.0 branch and have the poms indicating 2.0.x-SNAPSHOT. Some of the things I've learned in the last couple of years, just summarizing: Usually when you release something, you tag it. When there are problems on that release, you create a branch based on that tag, work some more, and tag that branch as 2.0.(x+1). Leave that branch there in case there's more trouble later on. Usually branches of previous versions are only kept open when support for previously released versions has to be continued. When we release 2.1 for instance, the 2.0 branch can be closed, and 2.1 is tagged (and optionally/probably branched too in a 2.1 branch). [On a side note, and probably not withing maven scope: since maven is all about 'project build best practices', I believe that, next to documenting 'our' views of the project structure (src/(main|test|whatever)/(java|resources|whatever), and splitting up projects into modules, we should also gather all best practices in release management (tagging/branching etc.) and put that on the site too. Maybe we can set the standard - sure would be nice if everybody everywhere works using the same standards, so I wouldn't have to convince people of a better way every time I'm on a new job :)) ] > If '2.0.x' isn't the best name for the maintenance branch of 2.0, then > another name is fine...I just don't want to constantly rename it to the > latest 2.0.whatever-we're-working-on. It's confusing, because then 2.0.1 > would be a tag on the 2.0.2 branch... > > | - whether to mark versions as -alpha, -beta along the way, or only label > | releases at those points (for 2.1 only on this) > > I think 2.0.1 should be -SNAPSHOT, then released, and on to 2.0.2 if > necessary. ack. I think X.Y.Z: X = total rewrite, not compatible with previous versions, Y = new features, Z = bugfix/maintenance release. > HOWEVER, for the 2.1 line I think we need to make some distinction about > the feature completeness of the release. -alpha, -beta, etc. is useful > here, IMO, since there will be some big new features that will have to > climb that maturity curve. Alpha is (as I understand from m2) a technology preview, in no way feature complete. That doesn't quite apply to 2.1. It's a feature addition. The new features might not work, but that's typical beta stuff. So maybe skip the alpha here, and just tag the beta-X, rc-X and final release. Before a beta is near, just use 2.1-SNAPSHOT (in the pom). After the first beta is released, we can (beta|rc)-(x+1)-SNAPSHOT until final release. On the other hand, something big like change the pom format to actually use attributes, i.e. <dependency groupId="..." artifactId="..." version="..." scope="test"/> would be a fundamental feature _change_ (instead of new features) and this would warrant a -alpha. So I think we need to decide whether to put out alpha's per 2.Y increment. > | - ensuring plugins remain compatible with 2.0. > > For the 2.0.x releases, this is undoubtedly critical. Perhaps we can > arrange some sort of CI process which will check this for us? A sort of > build farm for platform-as-maven-version, instead of OS-level platforms... Don't the integration tests take care of this? Btw, some previous releases required recompiles from plugins, but no code changes. We should have a mechanism to indicate a 'support' release that doesn't fix any bugs, just uses newer deps (this has been mentioned on the list before, by Brett IINM). Some mechanism like the pom-updates maybe (also useful for group-renames like plexus). > Beyond 2.0.x, though, I think we still need to verify that the > 2.1-targeted plugins are not poisoning the 2.0 execution. This will be > done through proper use of <prerequisites/>, but should be checked in CI > somehow...maybe with a plugin? :) what else? :) -- Kenney --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
