[jdf-dev] New versioning and organisation strategy

Pete Muir pmuir at redhat.com
Fri Jul 5 10:42:20 EDT 2013


Indeed we will :-)

On 5 Jul 2013, at 13:02, Max Rydahl Andersen <manderse at redhat.com> wrote:

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




More information about the jdf-dev mailing list