Re: [jdf-dev] New versioning and organisation strategy

Trying to grok consequences. On first read it seems it does not change anything - stacks.yml will just refer to these and we can use them. But will the archetypes still support enterprise=true|false flag ?

Will -qs-1 be adjusted to -qs-1-redhat-NN pattern when put into products or does that go away for these cases?

/max On Thu, Apr 25, 2013 at 10:55:44AM +0100, Pete Muir wrote: > Hi all, > > Rafael, Jason and I did a brainstorm about this at JUDCon Brazil, and came up with the following proposal: > > * jdf plugin for forge - longer term needs rolling into Forge core. This is issue https://issues.jboss.org/browse/FORGE-378. As this is proposed for Forge 2, we suggest not altering the version or group id of this plugin > * qstools - version scheme (starting 1.x) is good. Alter group id when we do the next major release only > * quickstarts > - change group id to follow products: > - org.jboss.quickstart.eap, org.jboss.quickstart.jdg etc. > - add a sandbox group id which covers quickstarts not in products > - change versions to follow products major.minor.micro version, with a qualifier to allow bug fixes: > - e.g. 6.0.1-qs-1, 6.0.1-qs-2 etc > * archetypes > - use group id scheme same as quickstarts but use org.jboss.archetype.eap etc. > - follow same version scheme as quickstarts, but use -atype-1 etc. > * BOMs > - use group id scheme same as quickstarts but use org.jboss.bom.eap etc. > - follow same version scheme as quickstarts, but use -bom-1 > - projects will be encouraged to create BOMs as well > > Let me know what you think, > > Pete > _______________________________________________ > jdf-dev mailing list > jdf-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jdf-dev