-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm replying to the top-level of the thread, since I'm not sure where else to attach my 2 cents. :)
<snip/> | - 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... 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. 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. | - 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... 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? :) | - segregation of the SVN tree to mirror our release process (some | thoughts in jira on this - essentially making archetypes, plugins and | the sandbox separate to to the main tree) +1, I think this is a GREAT idea. The mish-mash we have now is confusing to some users, who tend to think everything in there is on the same release cycle...and that's ignoring the obvious maintenance issues with having everything on the same trunk structure... | - how to manage versioning of plugins in JIRA I'm not an expert on jira, so I'll have to defer/proxy my vote to those who are. Hopefully, we could create a project per plugin, and manage multiple release schedules within a single project...is that possible? I mean, to support the 2.0 line as well as the 2.1 line... One thing we may need to address in the plugin realm is factoring of a single plugin into multiple API-compatibility lines (2.0 and 2.1), along with a common core API that actually implements the plugin functionality. This means that if you make a fix for a plugin that addresses the 2.0-compatible branch, and that fix changes core functionality, it will be included in the 2.1-compatible line, where there is appropriate overlap. It's not that significant, but it's something to keep in mind, IMO. Sorry for the late reply. I've been chewing on this for awhile now, and wanted to get my thoughts in order before replying. Cheers, john -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDXk2AK3h2CZwO/4URAgvGAJ0UQFQGc3UYuFHdnhrA+MfatyMySACfQcrh D+L8MJiB2c5XrmPMc9TZu2o= =2J0z -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
