12:18 p.m.
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(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jdf-dev
>
> _______________________________________________
> jdf-dev mailing list
> jdf-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jdf-dev