[jdf-dev] New versioning and organisation strategy

[Pete Muir]

It does, I think, do you see any concerns Jason?

On 5 Jul 2013, at 15:25, Rafael Benevides <benevides at redhat.com> wrote:

> Yes
> 
> Em 05/07/13 11:20, Jason Porter escreveu:
>> Will this incorporate the versioning changes we discussed at JUDCon:Brazil?
>> 
>> ----- Original Message -----
>>> From: "Rafael Benevides" <benevides at redhat.com>
>>> To: jdf-dev at lists.jboss.org, "Peter Muir" <pmuir at redhat.com>
>>> Sent: Thursday, July 4, 2013 8:22:29 AM
>>> Subject: Re: [jdf-dev] New versioning and organisation strategy
>>> 
>>> 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
>