[jdf-dev] New versioning and organisation strategy

[Pete Muir]

On 25 Apr 2013, at 23:27, Max Andersen <manderse at redhat.com> wrote:

> 
>> 
>> On 25 Apr 2013, at 14:46, Max Rydahl Andersen <manderse at redhat.com> wrote:
>> 
>>> 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 ?
>> 
>> No. They will be product only. There may be other upstream community archetypes, but they will be project specifically.
> 
> Okey - so either we need some extra metadata somewhere to know which archetype of now many to choose the right archetype for javaee project. 
> 
> Or we now require users to select specific runtime before starting to create a project (I would really not like that since its technically not needed). 
> 
> Also need to get something in to know which of the two repositories we need to add/suggest. Earlyaccess or the supported one. 
> 
> Note - I assume we'll
> Still introduce wildfly 8 etc into stacks.yml to get feedback/testing done early here, correct or?

Yes. I think we can still add upstream stuff to stacks. We may need a way to indicate this in the format as well.

>> 
>>> Will -qs-1 be adjusted to -qs-1-redhat-NN pattern when put into products or does that go away for these cases?
>> 
>> No, these are the product BOMs.
> 
> Ok. Any reason to not use -redhat then ?
> Is that because they will now be considered a separate deliverable ?

We didn't want to overload the meaning of -redhat-X, but we could do so if you guys think it is best.

> 
>> We would no longer bundle them in the product zip repos, instead just deliver them online via maven.repository.redhat.com
> 
> Okey so we can't count on them when users have just the zips for the offline mode. Just something to remember to copy when we go offline. 

Yes. These are now an overlay so don't belong to a particular project. I guess we could do a zip of the overlay if it's really needed.

>> 
>>> 
>>> /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
>>