[jdf-dev] New versioning and organisation strategy

[Rafael Benevides]

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