[jdf-dev] New versioning and organisation strategy

[Max Rydahl Andersen]

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 at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/jdf-dev