Indeed we will :-)
On 5 Jul 2013, at 13:02, Max Rydahl Andersen <manderse(a)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(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
>>
>
> _______________________________________________
> jdf-dev mailing list
> jdf-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jdf-dev