[jdf-dev] New versioning and organisation strategy

[Rafael Benevides]

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