[jdf-dev] New versioning and organisation strategy

[Max Rydahl Andersen]

We'll keep updating the stacks 1.0.0 format I hope since that is what JBDS 7.0 is going out with :)

In any case I'm leaving on PTO in ~3hrs for 3weeks so I can't personally give 
feedback before after that - I've cc'ed Fred and Rob which should be able to 
give some feedback too.

/max

On Thu, Jul 04, 2013 at 11:22:29AM -0300, Rafael Benevides wrote:
>After considering the feedback and after more brainstorming over the 
>migration plan, we have a now a more detailed and tunned proposal on 
>the new versioning and organization strategy. In the attached PDF you 
>will find this detailed plan with all artifacts changes needed.
>
>It's also a good opportunity to update stacks.yaml format (and client) 
>to 1.1.0
>
>Please, take a look on the attached plan and let us know what you 
>think about it. The migration work should start by now on developer 
>branches.
>
>Thank you
>
>Em 25/04/13 14:18, Rafael Benevides escreveu:
>>One thing that came in my mind is when to move the versions of 
>>Archetypes, Runtimes and BOMs to Stacks.yaml?
>>
>>I used to add only .Final (will be -bom-x) version of BOMs to 
>>Stacks.yaml.
>>
>>In the Case of Archetypes, I'm continuously updating it to the 
>>latest version (even being a CR - Candidate Release).
>>
>>For Runtimes, starting by EAP 6.1 Alpha (them Beta), I'm adding it 
>>with the "Early Access" label.
>>
>>Do we still follow this schema ?
>>
>>BOM: Only -bom-X release ?
>>Archetypes: Every -atype-X release ?
>>Runtime: Every "Early Access" and Product release ?
>>
>>By the way? How will we differ the "Candidate Release" from ".Final" 
>>Release ?
>>
>>Em 25/04/13 11:20, Marek Novotny escreveu:
>>>-----BEGIN PGP SIGNED MESSAGE-----
>>>Hash: SHA1
>>>
>>>On 04/25/2013 04:13 PM, Pete Muir 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.
>>>>
>>>>>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.
>>>>
>>>>We would no longer bundle them in the product zip repos, instead 
>>>>just deliver them online via maven.repository.redhat.com
>>>that supposes to finish/change the uploading process as
>>>maven.repository.redhat.com's content is currently only extracted
>>>product zips.
>>>>>/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
>>>>
>>>>_______________________________________________
>>>>jdf-dev mailing list
>>>>jdf-dev at lists.jboss.org
>>>>https://lists.jboss.org/mailman/listinfo/jdf-dev
>>>>
>>>
>>>- -- Marek Novotny
>>>- -- WFK and Seam Product Lead
>>>
>>>Red Hat Czech s.r.o.
>>>Purkynova 99
>>>612 45 Brno
>>>-----BEGIN PGP SIGNATURE-----
>>>Version: GnuPG v1.4.12 (GNU/Linux)
>>>Comment: Using GnuPG with undefined - http://www.enigmail.net/
>>>
>>>iEYEARECAAYFAlF5O8sACgkQU4HO8G8hNxXwkACdHa/hQ2cX1lF7FfjB7KblcaWF
>>>HZIAoLpXaKeyW4aEu9eWk/m+Pu75PvcY
>>>=68YA
>>>-----END PGP SIGNATURE-----
>>>_______________________________________________
>>>jdf-dev mailing list
>>>jdf-dev at lists.jboss.org
>>>https://lists.jboss.org/mailman/listinfo/jdf-dev
>>
>


>_______________________________________________
>jdf-dev mailing list
>jdf-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/jdf-dev