You are viewing a plain text version of this content. The canonical link for it is here.
Posted to easyant-dev@incubator.apache.org by Nicolas Lalevée <ni...@hibnet.org> on 2012/12/28 14:47:26 UTC
A first release process
So we have EasyAnt core, the end user executable, and the EasyAnt plugins, buildtypes and skeletons (the build.xml pieces) to release.
All core and plugins have a build based on EasyAnt. Since this build loop, I have setup some very basic build.xml so we can bootstrap a first release.
Here is the process I am suggesting:
- in plugins, buildtypes and skeletons:
-- do a svn tag.
-- invoke ant distributions: it will build a easyant-xxxx-0.9-src.zip package to be publish in the release area
-- invoke ant install-all: it will put every plugins into a shared repository locally on the build machine
- in core:
-- do a svn tag
-- invoke ant run -Dtarget=distribution: this is building easyant, and then running easyant with the plugins just installed in the shared repo. At the end we should have a easyant-core-0.9-bin.zip and a easyant-core-0.9-src.zip ready to be published in the release area
- push the *-src.zip and *-bin.zip into the staging release area
- md5, sha1 and sign the zip files
- vote for the release
Once the process released finished, the source of this 0.9 will be then available via 4 zip files. A zip distribution will be available to download for end user for immediate use.
And as an after release process, we would make the plugins, buildtypes and skeletons available via our repository on repo.easyant.org.
Does it sound good for everyone ?
Nicolas
Re: A first release process
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Note that we need a proper download page which follows the ASF guidelines.
More to read there:
http://www.apache.org/dev/release-download-pages.html
Nicolas
Le 27 févr. 2013 à 22:49, Jean-Louis Boudart <je...@gmail.com> a écrit :
> Release artifacts are available on dist.apache.org \o/
> I've just pushed all plugins to repository.easyant.org.
>
> I think last step is now to update the website (in particular download
> page) before anouncing publicly the release.
>
>
> 2013/1/28 Jean-Louis Boudart <je...@gmail.com>
>
>> Just tried modifying the version in revision attribute and i have the same
>> issue build failed without error even in debug. Let's debug this later.
>>
>>
>> Another solution is to set the version property like this :
>> <property name="version" value="${ivy.version}-incubating"/>
>>
>> It will force the version scheme in all produced files (manifest,
>> version.properties and each distribution archives).
>>
>> I prefer the shorter version easyant-core-0.9-incubating-bin.zip.
>>
>>
>>
>>
>>
>>
>> 2013/1/28 Nicolas Lalevée <ni...@hibnet.org>
>>
>>> Le 28 janv. 2013 à 10:16, Jean-Louis Boudart <je...@gmail.com>
>>> a écrit :
>>>
>>>> If this applies to core only, just updating the version attribute in
>>>> core/trunk/module.ivy should do the trick without any other changes.
>>>
>>> I have just tried that, the build fails at startup but without any error,
>>> it just look like a System.exit(1) somewhere...
>>>
>>> So in the module.ivy I would add a -incubating in the revision. So are we
>>> cool with that kind of name for the distribution artifact ?
>>> easyant-core-0.9-incubating-build-20130128010814-bin.zip
>>> For ASF, it is important that there is "incubating" and the version is
>>> clear enough. So this is a question mainly for us the PPMC. Should we
>>> prefer something shorter, like easyant-core-0.9-incubating-bin.zip, or the
>>> longer version.
>>> Personally, I don't mind if we choose one over the other.
>>> If we prefer the shorter version, is there any property which I could
>>> set, or should I just rename the artifact ?
>>>
>>>> Should we apply this version scheme also on buildtypes/skeletons etc… ?
>>>
>>> I will make sure the version on the archive of the source will have the
>>> "-incubating" suffix. For the version of each plugin, buildtype, skeleton
>>> in the module.ivy, I think we can stick with 0.9.
>>>
>>> Nicolas
>>>
>>>>
>>>>
>>>> 2013/1/28 Nicolas Lalevée <ni...@hibnet.org>
>>>>
>>>>> I had just a little trouble: the version should be 0.9-incubating.
>>>>> What is the best way to make easyant core build to produce a distrib
>>> with
>>>>> that version ?
>>>>> If the solution is to just rename the artifact afterwards, I don't
>>> mind,
>>>>> we can improve that later.
>>>>>
>>>>> Nicolas
>>>>>
>>>>> Le 25 janv. 2013 à 16:00, Nicolas Lalevée <ni...@hibnet.org>
>>> a
>>>>> écrit :
>>>>>
>>>>>> Le 24 janv. 2013 à 21:23, Jean-Louis Boudart <
>>>>> jeanlouis.boudart@gmail.com> a écrit :
>>>>>>
>>>>>>> Ivy 2.3.0 release is almost ready, artifacts reached maven central
>>> repo.
>>>>>>> Vote has ended without any veto. I assume official annouce is just a
>>>>>>> question of time now.
>>>>>>>
>>>>>>> Could we start our release process now ? :p
>>>>>>
>>>>>> Definitively.
>>>>>> I'll proceed soon, probably this week-end.
>>>>>>
>>>>>> Nicolas
>>>>>>
>>>>>>> Le 28 déc. 2012 22:53, "Nicolas Lalevée" <ni...@hibnet.org>
>>> a
>>>>>>> écrit :
>>>>>>>
>>>>>>>>
>>>>>>>> Le 28 déc. 2012 à 22:51, Nicolas Lalevée <
>>> nicolas.lalevee@hibnet.org>
>>>>> a
>>>>>>>> écrit :
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Le 28 déc. 2012 à 22:05, Jean-Louis Boudart <
>>>>> jeanlouis.boudart@gmail.com>
>>>>>>>> a écrit :
>>>>>>>>>
>>>>>>>>>> I was thinking about it this morning when i saw Maarten's mail.
>>>>>>>>>> Are we supposed to make a RC ? or directly a release?
>>>>>>>>>> If apache process forces us to make a RC, then we could do the
>>>>> release
>>>>>>>> with
>>>>>>>>>> current code base and then switch to 2.3.0-final.
>>>>>>>>>
>>>>>>>>> The ASF doesn't enforce anything about the quality of the code we
>>> are
>>>>>>>> releasing. It is "just" about IP, License, PMC vote (IMPC in our
>>> case),
>>>>>>>> source distribution and probably also the svn tagging. So we do
>>> what we
>>>>>>>> want about versioning of releases.
>>>>>>>>>
>>>>>>>>>> In other case i would be in favor of waiting ivy 2.3.0 final
>>> release.
>>>>>>>>>
>>>>>>>>> So we'll release an EasyAnt 0.9 with Ivy 2.3.
>>>>>>>>
>>>>>>>> Actually this will be a 0.9-incubating, as per the Incubator rules.
>>>>>>>>
>>>>>>>> Nicolas
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Nicolas
>>>>>>>>>
>>>>>>>>>> By the way, does it sound good if I try do a release just after
>>> the
>>>>>>>> release
>>>>>>>>>> of Ivy 2.3.0 (so we can use it in EasyAnt) ? Ivy release process
>>>>> should
>>>>>>>>>> start next week.
>>>>>>>>>>
>>>>>>>>>> Nicolas
>>>>>>>>>>
>>>>>>>>>> Le 28 déc. 2012 à 20:14, Jean-Louis Boudart <
>>>>>>>> jeanlouis.boudart@gmail.com> a
>>>>>>>>>> écrit :
>>>>>>>>>>
>>>>>>>>>>> Oki, maybe it's a premature discussion. Let's go as you described
>>>>> for
>>>>>>>> the
>>>>>>>>>>> first release and we will see in future how to enhance the
>>> process.
>>>>>>>>>>>
>>>>>>>>>>> So no objection for me :)
>>>>>>>>>>> Le 28 déc. 2012 19:19, "Nicolas Lalevée" <
>>>>> nicolas.lalevee@hibnet.org>
>>>>>>>> a
>>>>>>>>>>> écrit :
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Le 28 déc. 2012 à 17:42, Jean-Louis Boudart <
>>>>>>>> jeanlouis.boudart@gmail.com>
>>>>>>>>>>>> a écrit :
>>>>>>>>>>>>
>>>>>>>>>>>>> Sounds good for me.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But i'm wondering if it won't be safer to replace the step :
>>>>>>>>>>>>> * invoke ant install-all: it will put every plugins into a
>>> shared
>>>>>>>>>>>>> repository locally on the build machine
>>>>>>>>>>>>> by
>>>>>>>>>>>>> * invoke ant install-all: it will put every plugins into a
>>> staging
>>>>>>>>>>>>> repository on repo.easyant.org
>>>>>>>>>>>>>
>>>>>>>>>>>>> For the first release i agree that it doesn't change anything.
>>>>>>>>>>>>
>>>>>>>>>>>> The problem with that change is that only people having write
>>>>> access
>>>>>>>> to
>>>>>>>>>>>> repo.easyant.org could then build a distribution of easyant. We
>>>>> must
>>>>>>>> be
>>>>>>>>>>>> sure there is a simple enough process for people to build
>>> easyant
>>>>> from
>>>>>>>>>> the
>>>>>>>>>>>> sources.
>>>>>>>>>>>>
>>>>>>>>>>>>> But for future, plugins could be released individually. To make
>>>>> them
>>>>>>>>>>>>> accessible (as they will not be in the main distribution)
>>>>>>>>>>>>> repo.easyant.orgcould be a good host. Like for the main
>>>>> distribution,
>>>>>>>>>>>>> we could use a
>>>>>>>>>>>>> staging area to make them accessible before being definitivly
>>>>>>>> "public"
>>>>>>>>>>>> (or
>>>>>>>>>>>>> "stable").
>>>>>>>>>>>>>
>>>>>>>>>>>>> WDYT ?
>>>>>>>>>>>>
>>>>>>>>>>>> No objection. But we must make the difference between building a
>>>>>>>>>>>> distribution and releasing. Building a distribution should be
>>>>>>>> possible to
>>>>>>>>>>>> anyone having the sources. Making a release should then be
>>>>> building a
>>>>>>>>>>>> distribution but pushed onto Apache infra for the sources at
>>>>> least, or
>>>>>>>>>>>> somewhere else as repo.easyant.org for the binaries.
>>>>>>>>>>>>
>>>>>>>>>>>> Nicolas
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2012/12/28 Nicolas Lalevée <ni...@hibnet.org>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> So we have EasyAnt core, the end user executable, and the
>>> EasyAnt
>>>>>>>>>>>> plugins,
>>>>>>>>>>>>>> buildtypes and skeletons (the build.xml pieces) to release.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> All core and plugins have a build based on EasyAnt. Since this
>>>>> build
>>>>>>>>>>>> loop,
>>>>>>>>>>>>>> I have setup some very basic build.xml so we can bootstrap a
>>>>> first
>>>>>>>>>>>> release.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Here is the process I am suggesting:
>>>>>>>>>>>>>> - in plugins, buildtypes and skeletons:
>>>>>>>>>>>>>> -- do a svn tag.
>>>>>>>>>>>>>> -- invoke ant distributions: it will build a
>>>>>>>> easyant-xxxx-0.9-src.zip
>>>>>>>>>>>>>> package to be publish in the release area
>>>>>>>>>>>>>> -- invoke ant install-all: it will put every plugins into a
>>>>> shared
>>>>>>>>>>>>>> repository locally on the build machine
>>>>>>>>>>>>>> - in core:
>>>>>>>>>>>>>> -- do a svn tag
>>>>>>>>>>>>>> -- invoke ant run -Dtarget=distribution: this is building
>>>>> easyant,
>>>>>>>> and
>>>>>>>>>>>>>> then running easyant with the plugins just installed in the
>>>>> shared
>>>>>>>>>>>> repo. At
>>>>>>>>>>>>>> the end we should have a easyant-core-0.9-bin.zip and a
>>>>>>>>>>>>>> easyant-core-0.9-src.zip ready to be published in the release
>>>>> area
>>>>>>>>>>>>>> - push the *-src.zip and *-bin.zip into the staging release
>>> area
>>>>>>>>>>>>>> - md5, sha1 and sign the zip files
>>>>>>>>>>>>>> - vote for the release
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Once the process released finished, the source of this 0.9
>>> will
>>>>> be
>>>>>>>> then
>>>>>>>>>>>>>> available via 4 zip files. A zip distribution will be
>>> available
>>>>> to
>>>>>>>>>>>> download
>>>>>>>>>>>>>> for end user for immediate use.
>>>>>>>>>>>>>> And as an after release process, we would make the plugins,
>>>>>>>> buildtypes
>>>>>>>>>>>> and
>>>>>>>>>>>>>> skeletons available via our repository on repo.easyant.org.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Does it sound good for everyone ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nicolas
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Jean Louis Boudart
>>>>>>>>>>>>> Independent consultant
>>>>>>>>>>>>> Apache EasyAnt commiter http://incubator.apache.org/easyant/
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Jean Louis Boudart
>>>> Independent consultant
>>>> Apache EasyAnt commiter http://incubator.apache.org/easyant/
>>>
>>>
>>
>>
>> --
>> Jean Louis Boudart
>> Independent consultant
>> Apache EasyAnt commiter http://incubator.apache.org/easyant/
>>
>
>
>
> --
> Jean Louis Boudart
> Independent consultant
> Apache EasyAnt commiter http://incubator.apache.org/easyant/
Re: A first release process
Posted by Jean-Louis Boudart <je...@gmail.com>.
Release artifacts are available on dist.apache.org \o/
I've just pushed all plugins to repository.easyant.org.
I think last step is now to update the website (in particular download
page) before anouncing publicly the release.
2013/1/28 Jean-Louis Boudart <je...@gmail.com>
> Just tried modifying the version in revision attribute and i have the same
> issue build failed without error even in debug. Let's debug this later.
>
>
> Another solution is to set the version property like this :
> <property name="version" value="${ivy.version}-incubating"/>
>
> It will force the version scheme in all produced files (manifest,
> version.properties and each distribution archives).
>
> I prefer the shorter version easyant-core-0.9-incubating-bin.zip.
>
>
>
>
>
>
> 2013/1/28 Nicolas Lalevée <ni...@hibnet.org>
>
>> Le 28 janv. 2013 à 10:16, Jean-Louis Boudart <je...@gmail.com>
>> a écrit :
>>
>> > If this applies to core only, just updating the version attribute in
>> > core/trunk/module.ivy should do the trick without any other changes.
>>
>> I have just tried that, the build fails at startup but without any error,
>> it just look like a System.exit(1) somewhere...
>>
>> So in the module.ivy I would add a -incubating in the revision. So are we
>> cool with that kind of name for the distribution artifact ?
>> easyant-core-0.9-incubating-build-20130128010814-bin.zip
>> For ASF, it is important that there is "incubating" and the version is
>> clear enough. So this is a question mainly for us the PPMC. Should we
>> prefer something shorter, like easyant-core-0.9-incubating-bin.zip, or the
>> longer version.
>> Personally, I don't mind if we choose one over the other.
>> If we prefer the shorter version, is there any property which I could
>> set, or should I just rename the artifact ?
>>
>> > Should we apply this version scheme also on buildtypes/skeletons etc… ?
>>
>> I will make sure the version on the archive of the source will have the
>> "-incubating" suffix. For the version of each plugin, buildtype, skeleton
>> in the module.ivy, I think we can stick with 0.9.
>>
>> Nicolas
>>
>> >
>> >
>> > 2013/1/28 Nicolas Lalevée <ni...@hibnet.org>
>> >
>> >> I had just a little trouble: the version should be 0.9-incubating.
>> >> What is the best way to make easyant core build to produce a distrib
>> with
>> >> that version ?
>> >> If the solution is to just rename the artifact afterwards, I don't
>> mind,
>> >> we can improve that later.
>> >>
>> >> Nicolas
>> >>
>> >> Le 25 janv. 2013 à 16:00, Nicolas Lalevée <ni...@hibnet.org>
>> a
>> >> écrit :
>> >>
>> >>> Le 24 janv. 2013 à 21:23, Jean-Louis Boudart <
>> >> jeanlouis.boudart@gmail.com> a écrit :
>> >>>
>> >>>> Ivy 2.3.0 release is almost ready, artifacts reached maven central
>> repo.
>> >>>> Vote has ended without any veto. I assume official annouce is just a
>> >>>> question of time now.
>> >>>>
>> >>>> Could we start our release process now ? :p
>> >>>
>> >>> Definitively.
>> >>> I'll proceed soon, probably this week-end.
>> >>>
>> >>> Nicolas
>> >>>
>> >>>> Le 28 déc. 2012 22:53, "Nicolas Lalevée" <ni...@hibnet.org>
>> a
>> >>>> écrit :
>> >>>>
>> >>>>>
>> >>>>> Le 28 déc. 2012 à 22:51, Nicolas Lalevée <
>> nicolas.lalevee@hibnet.org>
>> >> a
>> >>>>> écrit :
>> >>>>>
>> >>>>>>
>> >>>>>> Le 28 déc. 2012 à 22:05, Jean-Louis Boudart <
>> >> jeanlouis.boudart@gmail.com>
>> >>>>> a écrit :
>> >>>>>>
>> >>>>>>> I was thinking about it this morning when i saw Maarten's mail.
>> >>>>>>> Are we supposed to make a RC ? or directly a release?
>> >>>>>>> If apache process forces us to make a RC, then we could do the
>> >> release
>> >>>>> with
>> >>>>>>> current code base and then switch to 2.3.0-final.
>> >>>>>>
>> >>>>>> The ASF doesn't enforce anything about the quality of the code we
>> are
>> >>>>> releasing. It is "just" about IP, License, PMC vote (IMPC in our
>> case),
>> >>>>> source distribution and probably also the svn tagging. So we do
>> what we
>> >>>>> want about versioning of releases.
>> >>>>>>
>> >>>>>>> In other case i would be in favor of waiting ivy 2.3.0 final
>> release.
>> >>>>>>
>> >>>>>> So we'll release an EasyAnt 0.9 with Ivy 2.3.
>> >>>>>
>> >>>>> Actually this will be a 0.9-incubating, as per the Incubator rules.
>> >>>>>
>> >>>>> Nicolas
>> >>>>>
>> >>>>>>
>> >>>>>> Nicolas
>> >>>>>>
>> >>>>>>> By the way, does it sound good if I try do a release just after
>> the
>> >>>>> release
>> >>>>>>> of Ivy 2.3.0 (so we can use it in EasyAnt) ? Ivy release process
>> >> should
>> >>>>>>> start next week.
>> >>>>>>>
>> >>>>>>> Nicolas
>> >>>>>>>
>> >>>>>>> Le 28 déc. 2012 à 20:14, Jean-Louis Boudart <
>> >>>>> jeanlouis.boudart@gmail.com> a
>> >>>>>>> écrit :
>> >>>>>>>
>> >>>>>>>> Oki, maybe it's a premature discussion. Let's go as you described
>> >> for
>> >>>>> the
>> >>>>>>>> first release and we will see in future how to enhance the
>> process.
>> >>>>>>>>
>> >>>>>>>> So no objection for me :)
>> >>>>>>>> Le 28 déc. 2012 19:19, "Nicolas Lalevée" <
>> >> nicolas.lalevee@hibnet.org>
>> >>>>> a
>> >>>>>>>> écrit :
>> >>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> Le 28 déc. 2012 à 17:42, Jean-Louis Boudart <
>> >>>>> jeanlouis.boudart@gmail.com>
>> >>>>>>>>> a écrit :
>> >>>>>>>>>
>> >>>>>>>>>> Sounds good for me.
>> >>>>>>>>>>
>> >>>>>>>>>> But i'm wondering if it won't be safer to replace the step :
>> >>>>>>>>>> * invoke ant install-all: it will put every plugins into a
>> shared
>> >>>>>>>>>> repository locally on the build machine
>> >>>>>>>>>> by
>> >>>>>>>>>> * invoke ant install-all: it will put every plugins into a
>> staging
>> >>>>>>>>>> repository on repo.easyant.org
>> >>>>>>>>>>
>> >>>>>>>>>> For the first release i agree that it doesn't change anything.
>> >>>>>>>>>
>> >>>>>>>>> The problem with that change is that only people having write
>> >> access
>> >>>>> to
>> >>>>>>>>> repo.easyant.org could then build a distribution of easyant. We
>> >> must
>> >>>>> be
>> >>>>>>>>> sure there is a simple enough process for people to build
>> easyant
>> >> from
>> >>>>>>> the
>> >>>>>>>>> sources.
>> >>>>>>>>>
>> >>>>>>>>>> But for future, plugins could be released individually. To make
>> >> them
>> >>>>>>>>>> accessible (as they will not be in the main distribution)
>> >>>>>>>>>> repo.easyant.orgcould be a good host. Like for the main
>> >> distribution,
>> >>>>>>>>>> we could use a
>> >>>>>>>>>> staging area to make them accessible before being definitivly
>> >>>>> "public"
>> >>>>>>>>> (or
>> >>>>>>>>>> "stable").
>> >>>>>>>>>>
>> >>>>>>>>>> WDYT ?
>> >>>>>>>>>
>> >>>>>>>>> No objection. But we must make the difference between building a
>> >>>>>>>>> distribution and releasing. Building a distribution should be
>> >>>>> possible to
>> >>>>>>>>> anyone having the sources. Making a release should then be
>> >> building a
>> >>>>>>>>> distribution but pushed onto Apache infra for the sources at
>> >> least, or
>> >>>>>>>>> somewhere else as repo.easyant.org for the binaries.
>> >>>>>>>>>
>> >>>>>>>>> Nicolas
>> >>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> 2012/12/28 Nicolas Lalevée <ni...@hibnet.org>
>> >>>>>>>>>>
>> >>>>>>>>>>> So we have EasyAnt core, the end user executable, and the
>> EasyAnt
>> >>>>>>>>> plugins,
>> >>>>>>>>>>> buildtypes and skeletons (the build.xml pieces) to release.
>> >>>>>>>>>>>
>> >>>>>>>>>>> All core and plugins have a build based on EasyAnt. Since this
>> >> build
>> >>>>>>>>> loop,
>> >>>>>>>>>>> I have setup some very basic build.xml so we can bootstrap a
>> >> first
>> >>>>>>>>> release.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Here is the process I am suggesting:
>> >>>>>>>>>>> - in plugins, buildtypes and skeletons:
>> >>>>>>>>>>> -- do a svn tag.
>> >>>>>>>>>>> -- invoke ant distributions: it will build a
>> >>>>> easyant-xxxx-0.9-src.zip
>> >>>>>>>>>>> package to be publish in the release area
>> >>>>>>>>>>> -- invoke ant install-all: it will put every plugins into a
>> >> shared
>> >>>>>>>>>>> repository locally on the build machine
>> >>>>>>>>>>> - in core:
>> >>>>>>>>>>> -- do a svn tag
>> >>>>>>>>>>> -- invoke ant run -Dtarget=distribution: this is building
>> >> easyant,
>> >>>>> and
>> >>>>>>>>>>> then running easyant with the plugins just installed in the
>> >> shared
>> >>>>>>>>> repo. At
>> >>>>>>>>>>> the end we should have a easyant-core-0.9-bin.zip and a
>> >>>>>>>>>>> easyant-core-0.9-src.zip ready to be published in the release
>> >> area
>> >>>>>>>>>>> - push the *-src.zip and *-bin.zip into the staging release
>> area
>> >>>>>>>>>>> - md5, sha1 and sign the zip files
>> >>>>>>>>>>> - vote for the release
>> >>>>>>>>>>>
>> >>>>>>>>>>> Once the process released finished, the source of this 0.9
>> will
>> >> be
>> >>>>> then
>> >>>>>>>>>>> available via 4 zip files. A zip distribution will be
>> available
>> >> to
>> >>>>>>>>> download
>> >>>>>>>>>>> for end user for immediate use.
>> >>>>>>>>>>> And as an after release process, we would make the plugins,
>> >>>>> buildtypes
>> >>>>>>>>> and
>> >>>>>>>>>>> skeletons available via our repository on repo.easyant.org.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Does it sound good for everyone ?
>> >>>>>>>>>>>
>> >>>>>>>>>>> Nicolas
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> --
>> >>>>>>>>>> Jean Louis Boudart
>> >>>>>>>>>> Independent consultant
>> >>>>>>>>>> Apache EasyAnt commiter http://incubator.apache.org/easyant/
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>
>> >>
>> >>
>> >
>> >
>> > --
>> > Jean Louis Boudart
>> > Independent consultant
>> > Apache EasyAnt commiter http://incubator.apache.org/easyant/
>>
>>
>
>
> --
> Jean Louis Boudart
> Independent consultant
> Apache EasyAnt commiter http://incubator.apache.org/easyant/
>
--
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://incubator.apache.org/easyant/
Re: A first release process
Posted by Jean-Louis Boudart <je...@gmail.com>.
Just tried modifying the version in revision attribute and i have the same
issue build failed without error even in debug. Let's debug this later.
Another solution is to set the version property like this :
<property name="version" value="${ivy.version}-incubating"/>
It will force the version scheme in all produced files (manifest,
version.properties and each distribution archives).
I prefer the shorter version easyant-core-0.9-incubating-bin.zip.
2013/1/28 Nicolas Lalevée <ni...@hibnet.org>
> Le 28 janv. 2013 à 10:16, Jean-Louis Boudart <je...@gmail.com>
> a écrit :
>
> > If this applies to core only, just updating the version attribute in
> > core/trunk/module.ivy should do the trick without any other changes.
>
> I have just tried that, the build fails at startup but without any error,
> it just look like a System.exit(1) somewhere...
>
> So in the module.ivy I would add a -incubating in the revision. So are we
> cool with that kind of name for the distribution artifact ?
> easyant-core-0.9-incubating-build-20130128010814-bin.zip
> For ASF, it is important that there is "incubating" and the version is
> clear enough. So this is a question mainly for us the PPMC. Should we
> prefer something shorter, like easyant-core-0.9-incubating-bin.zip, or the
> longer version.
> Personally, I don't mind if we choose one over the other.
> If we prefer the shorter version, is there any property which I could set,
> or should I just rename the artifact ?
>
> > Should we apply this version scheme also on buildtypes/skeletons etc… ?
>
> I will make sure the version on the archive of the source will have the
> "-incubating" suffix. For the version of each plugin, buildtype, skeleton
> in the module.ivy, I think we can stick with 0.9.
>
> Nicolas
>
> >
> >
> > 2013/1/28 Nicolas Lalevée <ni...@hibnet.org>
> >
> >> I had just a little trouble: the version should be 0.9-incubating.
> >> What is the best way to make easyant core build to produce a distrib
> with
> >> that version ?
> >> If the solution is to just rename the artifact afterwards, I don't mind,
> >> we can improve that later.
> >>
> >> Nicolas
> >>
> >> Le 25 janv. 2013 à 16:00, Nicolas Lalevée <ni...@hibnet.org>
> a
> >> écrit :
> >>
> >>> Le 24 janv. 2013 à 21:23, Jean-Louis Boudart <
> >> jeanlouis.boudart@gmail.com> a écrit :
> >>>
> >>>> Ivy 2.3.0 release is almost ready, artifacts reached maven central
> repo.
> >>>> Vote has ended without any veto. I assume official annouce is just a
> >>>> question of time now.
> >>>>
> >>>> Could we start our release process now ? :p
> >>>
> >>> Definitively.
> >>> I'll proceed soon, probably this week-end.
> >>>
> >>> Nicolas
> >>>
> >>>> Le 28 déc. 2012 22:53, "Nicolas Lalevée" <ni...@hibnet.org>
> a
> >>>> écrit :
> >>>>
> >>>>>
> >>>>> Le 28 déc. 2012 à 22:51, Nicolas Lalevée <nicolas.lalevee@hibnet.org
> >
> >> a
> >>>>> écrit :
> >>>>>
> >>>>>>
> >>>>>> Le 28 déc. 2012 à 22:05, Jean-Louis Boudart <
> >> jeanlouis.boudart@gmail.com>
> >>>>> a écrit :
> >>>>>>
> >>>>>>> I was thinking about it this morning when i saw Maarten's mail.
> >>>>>>> Are we supposed to make a RC ? or directly a release?
> >>>>>>> If apache process forces us to make a RC, then we could do the
> >> release
> >>>>> with
> >>>>>>> current code base and then switch to 2.3.0-final.
> >>>>>>
> >>>>>> The ASF doesn't enforce anything about the quality of the code we
> are
> >>>>> releasing. It is "just" about IP, License, PMC vote (IMPC in our
> case),
> >>>>> source distribution and probably also the svn tagging. So we do what
> we
> >>>>> want about versioning of releases.
> >>>>>>
> >>>>>>> In other case i would be in favor of waiting ivy 2.3.0 final
> release.
> >>>>>>
> >>>>>> So we'll release an EasyAnt 0.9 with Ivy 2.3.
> >>>>>
> >>>>> Actually this will be a 0.9-incubating, as per the Incubator rules.
> >>>>>
> >>>>> Nicolas
> >>>>>
> >>>>>>
> >>>>>> Nicolas
> >>>>>>
> >>>>>>> By the way, does it sound good if I try do a release just after the
> >>>>> release
> >>>>>>> of Ivy 2.3.0 (so we can use it in EasyAnt) ? Ivy release process
> >> should
> >>>>>>> start next week.
> >>>>>>>
> >>>>>>> Nicolas
> >>>>>>>
> >>>>>>> Le 28 déc. 2012 à 20:14, Jean-Louis Boudart <
> >>>>> jeanlouis.boudart@gmail.com> a
> >>>>>>> écrit :
> >>>>>>>
> >>>>>>>> Oki, maybe it's a premature discussion. Let's go as you described
> >> for
> >>>>> the
> >>>>>>>> first release and we will see in future how to enhance the
> process.
> >>>>>>>>
> >>>>>>>> So no objection for me :)
> >>>>>>>> Le 28 déc. 2012 19:19, "Nicolas Lalevée" <
> >> nicolas.lalevee@hibnet.org>
> >>>>> a
> >>>>>>>> écrit :
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Le 28 déc. 2012 à 17:42, Jean-Louis Boudart <
> >>>>> jeanlouis.boudart@gmail.com>
> >>>>>>>>> a écrit :
> >>>>>>>>>
> >>>>>>>>>> Sounds good for me.
> >>>>>>>>>>
> >>>>>>>>>> But i'm wondering if it won't be safer to replace the step :
> >>>>>>>>>> * invoke ant install-all: it will put every plugins into a
> shared
> >>>>>>>>>> repository locally on the build machine
> >>>>>>>>>> by
> >>>>>>>>>> * invoke ant install-all: it will put every plugins into a
> staging
> >>>>>>>>>> repository on repo.easyant.org
> >>>>>>>>>>
> >>>>>>>>>> For the first release i agree that it doesn't change anything.
> >>>>>>>>>
> >>>>>>>>> The problem with that change is that only people having write
> >> access
> >>>>> to
> >>>>>>>>> repo.easyant.org could then build a distribution of easyant. We
> >> must
> >>>>> be
> >>>>>>>>> sure there is a simple enough process for people to build easyant
> >> from
> >>>>>>> the
> >>>>>>>>> sources.
> >>>>>>>>>
> >>>>>>>>>> But for future, plugins could be released individually. To make
> >> them
> >>>>>>>>>> accessible (as they will not be in the main distribution)
> >>>>>>>>>> repo.easyant.orgcould be a good host. Like for the main
> >> distribution,
> >>>>>>>>>> we could use a
> >>>>>>>>>> staging area to make them accessible before being definitivly
> >>>>> "public"
> >>>>>>>>> (or
> >>>>>>>>>> "stable").
> >>>>>>>>>>
> >>>>>>>>>> WDYT ?
> >>>>>>>>>
> >>>>>>>>> No objection. But we must make the difference between building a
> >>>>>>>>> distribution and releasing. Building a distribution should be
> >>>>> possible to
> >>>>>>>>> anyone having the sources. Making a release should then be
> >> building a
> >>>>>>>>> distribution but pushed onto Apache infra for the sources at
> >> least, or
> >>>>>>>>> somewhere else as repo.easyant.org for the binaries.
> >>>>>>>>>
> >>>>>>>>> Nicolas
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 2012/12/28 Nicolas Lalevée <ni...@hibnet.org>
> >>>>>>>>>>
> >>>>>>>>>>> So we have EasyAnt core, the end user executable, and the
> EasyAnt
> >>>>>>>>> plugins,
> >>>>>>>>>>> buildtypes and skeletons (the build.xml pieces) to release.
> >>>>>>>>>>>
> >>>>>>>>>>> All core and plugins have a build based on EasyAnt. Since this
> >> build
> >>>>>>>>> loop,
> >>>>>>>>>>> I have setup some very basic build.xml so we can bootstrap a
> >> first
> >>>>>>>>> release.
> >>>>>>>>>>>
> >>>>>>>>>>> Here is the process I am suggesting:
> >>>>>>>>>>> - in plugins, buildtypes and skeletons:
> >>>>>>>>>>> -- do a svn tag.
> >>>>>>>>>>> -- invoke ant distributions: it will build a
> >>>>> easyant-xxxx-0.9-src.zip
> >>>>>>>>>>> package to be publish in the release area
> >>>>>>>>>>> -- invoke ant install-all: it will put every plugins into a
> >> shared
> >>>>>>>>>>> repository locally on the build machine
> >>>>>>>>>>> - in core:
> >>>>>>>>>>> -- do a svn tag
> >>>>>>>>>>> -- invoke ant run -Dtarget=distribution: this is building
> >> easyant,
> >>>>> and
> >>>>>>>>>>> then running easyant with the plugins just installed in the
> >> shared
> >>>>>>>>> repo. At
> >>>>>>>>>>> the end we should have a easyant-core-0.9-bin.zip and a
> >>>>>>>>>>> easyant-core-0.9-src.zip ready to be published in the release
> >> area
> >>>>>>>>>>> - push the *-src.zip and *-bin.zip into the staging release
> area
> >>>>>>>>>>> - md5, sha1 and sign the zip files
> >>>>>>>>>>> - vote for the release
> >>>>>>>>>>>
> >>>>>>>>>>> Once the process released finished, the source of this 0.9 will
> >> be
> >>>>> then
> >>>>>>>>>>> available via 4 zip files. A zip distribution will be available
> >> to
> >>>>>>>>> download
> >>>>>>>>>>> for end user for immediate use.
> >>>>>>>>>>> And as an after release process, we would make the plugins,
> >>>>> buildtypes
> >>>>>>>>> and
> >>>>>>>>>>> skeletons available via our repository on repo.easyant.org.
> >>>>>>>>>>>
> >>>>>>>>>>> Does it sound good for everyone ?
> >>>>>>>>>>>
> >>>>>>>>>>> Nicolas
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Jean Louis Boudart
> >>>>>>>>>> Independent consultant
> >>>>>>>>>> Apache EasyAnt commiter http://incubator.apache.org/easyant/
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>
> >>
> >>
> >
> >
> > --
> > Jean Louis Boudart
> > Independent consultant
> > Apache EasyAnt commiter http://incubator.apache.org/easyant/
>
>
--
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://incubator.apache.org/easyant/
Re: A first release process
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le 28 janv. 2013 à 10:16, Jean-Louis Boudart <je...@gmail.com> a écrit :
> If this applies to core only, just updating the version attribute in
> core/trunk/module.ivy should do the trick without any other changes.
I have just tried that, the build fails at startup but without any error, it just look like a System.exit(1) somewhere...
So in the module.ivy I would add a -incubating in the revision. So are we cool with that kind of name for the distribution artifact ?
easyant-core-0.9-incubating-build-20130128010814-bin.zip
For ASF, it is important that there is "incubating" and the version is clear enough. So this is a question mainly for us the PPMC. Should we prefer something shorter, like easyant-core-0.9-incubating-bin.zip, or the longer version.
Personally, I don't mind if we choose one over the other.
If we prefer the shorter version, is there any property which I could set, or should I just rename the artifact ?
> Should we apply this version scheme also on buildtypes/skeletons etc… ?
I will make sure the version on the archive of the source will have the "-incubating" suffix. For the version of each plugin, buildtype, skeleton in the module.ivy, I think we can stick with 0.9.
Nicolas
>
>
> 2013/1/28 Nicolas Lalevée <ni...@hibnet.org>
>
>> I had just a little trouble: the version should be 0.9-incubating.
>> What is the best way to make easyant core build to produce a distrib with
>> that version ?
>> If the solution is to just rename the artifact afterwards, I don't mind,
>> we can improve that later.
>>
>> Nicolas
>>
>> Le 25 janv. 2013 à 16:00, Nicolas Lalevée <ni...@hibnet.org> a
>> écrit :
>>
>>> Le 24 janv. 2013 à 21:23, Jean-Louis Boudart <
>> jeanlouis.boudart@gmail.com> a écrit :
>>>
>>>> Ivy 2.3.0 release is almost ready, artifacts reached maven central repo.
>>>> Vote has ended without any veto. I assume official annouce is just a
>>>> question of time now.
>>>>
>>>> Could we start our release process now ? :p
>>>
>>> Definitively.
>>> I'll proceed soon, probably this week-end.
>>>
>>> Nicolas
>>>
>>>> Le 28 déc. 2012 22:53, "Nicolas Lalevée" <ni...@hibnet.org> a
>>>> écrit :
>>>>
>>>>>
>>>>> Le 28 déc. 2012 à 22:51, Nicolas Lalevée <ni...@hibnet.org>
>> a
>>>>> écrit :
>>>>>
>>>>>>
>>>>>> Le 28 déc. 2012 à 22:05, Jean-Louis Boudart <
>> jeanlouis.boudart@gmail.com>
>>>>> a écrit :
>>>>>>
>>>>>>> I was thinking about it this morning when i saw Maarten's mail.
>>>>>>> Are we supposed to make a RC ? or directly a release?
>>>>>>> If apache process forces us to make a RC, then we could do the
>> release
>>>>> with
>>>>>>> current code base and then switch to 2.3.0-final.
>>>>>>
>>>>>> The ASF doesn't enforce anything about the quality of the code we are
>>>>> releasing. It is "just" about IP, License, PMC vote (IMPC in our case),
>>>>> source distribution and probably also the svn tagging. So we do what we
>>>>> want about versioning of releases.
>>>>>>
>>>>>>> In other case i would be in favor of waiting ivy 2.3.0 final release.
>>>>>>
>>>>>> So we'll release an EasyAnt 0.9 with Ivy 2.3.
>>>>>
>>>>> Actually this will be a 0.9-incubating, as per the Incubator rules.
>>>>>
>>>>> Nicolas
>>>>>
>>>>>>
>>>>>> Nicolas
>>>>>>
>>>>>>> By the way, does it sound good if I try do a release just after the
>>>>> release
>>>>>>> of Ivy 2.3.0 (so we can use it in EasyAnt) ? Ivy release process
>> should
>>>>>>> start next week.
>>>>>>>
>>>>>>> Nicolas
>>>>>>>
>>>>>>> Le 28 déc. 2012 à 20:14, Jean-Louis Boudart <
>>>>> jeanlouis.boudart@gmail.com> a
>>>>>>> écrit :
>>>>>>>
>>>>>>>> Oki, maybe it's a premature discussion. Let's go as you described
>> for
>>>>> the
>>>>>>>> first release and we will see in future how to enhance the process.
>>>>>>>>
>>>>>>>> So no objection for me :)
>>>>>>>> Le 28 déc. 2012 19:19, "Nicolas Lalevée" <
>> nicolas.lalevee@hibnet.org>
>>>>> a
>>>>>>>> écrit :
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Le 28 déc. 2012 à 17:42, Jean-Louis Boudart <
>>>>> jeanlouis.boudart@gmail.com>
>>>>>>>>> a écrit :
>>>>>>>>>
>>>>>>>>>> Sounds good for me.
>>>>>>>>>>
>>>>>>>>>> But i'm wondering if it won't be safer to replace the step :
>>>>>>>>>> * invoke ant install-all: it will put every plugins into a shared
>>>>>>>>>> repository locally on the build machine
>>>>>>>>>> by
>>>>>>>>>> * invoke ant install-all: it will put every plugins into a staging
>>>>>>>>>> repository on repo.easyant.org
>>>>>>>>>>
>>>>>>>>>> For the first release i agree that it doesn't change anything.
>>>>>>>>>
>>>>>>>>> The problem with that change is that only people having write
>> access
>>>>> to
>>>>>>>>> repo.easyant.org could then build a distribution of easyant. We
>> must
>>>>> be
>>>>>>>>> sure there is a simple enough process for people to build easyant
>> from
>>>>>>> the
>>>>>>>>> sources.
>>>>>>>>>
>>>>>>>>>> But for future, plugins could be released individually. To make
>> them
>>>>>>>>>> accessible (as they will not be in the main distribution)
>>>>>>>>>> repo.easyant.orgcould be a good host. Like for the main
>> distribution,
>>>>>>>>>> we could use a
>>>>>>>>>> staging area to make them accessible before being definitivly
>>>>> "public"
>>>>>>>>> (or
>>>>>>>>>> "stable").
>>>>>>>>>>
>>>>>>>>>> WDYT ?
>>>>>>>>>
>>>>>>>>> No objection. But we must make the difference between building a
>>>>>>>>> distribution and releasing. Building a distribution should be
>>>>> possible to
>>>>>>>>> anyone having the sources. Making a release should then be
>> building a
>>>>>>>>> distribution but pushed onto Apache infra for the sources at
>> least, or
>>>>>>>>> somewhere else as repo.easyant.org for the binaries.
>>>>>>>>>
>>>>>>>>> Nicolas
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2012/12/28 Nicolas Lalevée <ni...@hibnet.org>
>>>>>>>>>>
>>>>>>>>>>> So we have EasyAnt core, the end user executable, and the EasyAnt
>>>>>>>>> plugins,
>>>>>>>>>>> buildtypes and skeletons (the build.xml pieces) to release.
>>>>>>>>>>>
>>>>>>>>>>> All core and plugins have a build based on EasyAnt. Since this
>> build
>>>>>>>>> loop,
>>>>>>>>>>> I have setup some very basic build.xml so we can bootstrap a
>> first
>>>>>>>>> release.
>>>>>>>>>>>
>>>>>>>>>>> Here is the process I am suggesting:
>>>>>>>>>>> - in plugins, buildtypes and skeletons:
>>>>>>>>>>> -- do a svn tag.
>>>>>>>>>>> -- invoke ant distributions: it will build a
>>>>> easyant-xxxx-0.9-src.zip
>>>>>>>>>>> package to be publish in the release area
>>>>>>>>>>> -- invoke ant install-all: it will put every plugins into a
>> shared
>>>>>>>>>>> repository locally on the build machine
>>>>>>>>>>> - in core:
>>>>>>>>>>> -- do a svn tag
>>>>>>>>>>> -- invoke ant run -Dtarget=distribution: this is building
>> easyant,
>>>>> and
>>>>>>>>>>> then running easyant with the plugins just installed in the
>> shared
>>>>>>>>> repo. At
>>>>>>>>>>> the end we should have a easyant-core-0.9-bin.zip and a
>>>>>>>>>>> easyant-core-0.9-src.zip ready to be published in the release
>> area
>>>>>>>>>>> - push the *-src.zip and *-bin.zip into the staging release area
>>>>>>>>>>> - md5, sha1 and sign the zip files
>>>>>>>>>>> - vote for the release
>>>>>>>>>>>
>>>>>>>>>>> Once the process released finished, the source of this 0.9 will
>> be
>>>>> then
>>>>>>>>>>> available via 4 zip files. A zip distribution will be available
>> to
>>>>>>>>> download
>>>>>>>>>>> for end user for immediate use.
>>>>>>>>>>> And as an after release process, we would make the plugins,
>>>>> buildtypes
>>>>>>>>> and
>>>>>>>>>>> skeletons available via our repository on repo.easyant.org.
>>>>>>>>>>>
>>>>>>>>>>> Does it sound good for everyone ?
>>>>>>>>>>>
>>>>>>>>>>> Nicolas
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Jean Louis Boudart
>>>>>>>>>> Independent consultant
>>>>>>>>>> Apache EasyAnt commiter http://incubator.apache.org/easyant/
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>
>>
>
>
> --
> Jean Louis Boudart
> Independent consultant
> Apache EasyAnt commiter http://incubator.apache.org/easyant/
Re: A first release process
Posted by Jean-Louis Boudart <je...@gmail.com>.
If this applies to core only, just updating the version attribute in
core/trunk/module.ivy should do the trick without any other changes.
Should we apply this version scheme also on buildtypes/skeletons etc... ?
2013/1/28 Nicolas Lalevée <ni...@hibnet.org>
> I had just a little trouble: the version should be 0.9-incubating.
> What is the best way to make easyant core build to produce a distrib with
> that version ?
> If the solution is to just rename the artifact afterwards, I don't mind,
> we can improve that later.
>
> Nicolas
>
> Le 25 janv. 2013 à 16:00, Nicolas Lalevée <ni...@hibnet.org> a
> écrit :
>
> > Le 24 janv. 2013 à 21:23, Jean-Louis Boudart <
> jeanlouis.boudart@gmail.com> a écrit :
> >
> >> Ivy 2.3.0 release is almost ready, artifacts reached maven central repo.
> >> Vote has ended without any veto. I assume official annouce is just a
> >> question of time now.
> >>
> >> Could we start our release process now ? :p
> >
> > Definitively.
> > I'll proceed soon, probably this week-end.
> >
> > Nicolas
> >
> >> Le 28 déc. 2012 22:53, "Nicolas Lalevée" <ni...@hibnet.org> a
> >> écrit :
> >>
> >>>
> >>> Le 28 déc. 2012 à 22:51, Nicolas Lalevée <ni...@hibnet.org>
> a
> >>> écrit :
> >>>
> >>>>
> >>>> Le 28 déc. 2012 à 22:05, Jean-Louis Boudart <
> jeanlouis.boudart@gmail.com>
> >>> a écrit :
> >>>>
> >>>>> I was thinking about it this morning when i saw Maarten's mail.
> >>>>> Are we supposed to make a RC ? or directly a release?
> >>>>> If apache process forces us to make a RC, then we could do the
> release
> >>> with
> >>>>> current code base and then switch to 2.3.0-final.
> >>>>
> >>>> The ASF doesn't enforce anything about the quality of the code we are
> >>> releasing. It is "just" about IP, License, PMC vote (IMPC in our case),
> >>> source distribution and probably also the svn tagging. So we do what we
> >>> want about versioning of releases.
> >>>>
> >>>>> In other case i would be in favor of waiting ivy 2.3.0 final release.
> >>>>
> >>>> So we'll release an EasyAnt 0.9 with Ivy 2.3.
> >>>
> >>> Actually this will be a 0.9-incubating, as per the Incubator rules.
> >>>
> >>> Nicolas
> >>>
> >>>>
> >>>> Nicolas
> >>>>
> >>>>> By the way, does it sound good if I try do a release just after the
> >>> release
> >>>>> of Ivy 2.3.0 (so we can use it in EasyAnt) ? Ivy release process
> should
> >>>>> start next week.
> >>>>>
> >>>>> Nicolas
> >>>>>
> >>>>> Le 28 déc. 2012 à 20:14, Jean-Louis Boudart <
> >>> jeanlouis.boudart@gmail.com> a
> >>>>> écrit :
> >>>>>
> >>>>>> Oki, maybe it's a premature discussion. Let's go as you described
> for
> >>> the
> >>>>>> first release and we will see in future how to enhance the process.
> >>>>>>
> >>>>>> So no objection for me :)
> >>>>>> Le 28 déc. 2012 19:19, "Nicolas Lalevée" <
> nicolas.lalevee@hibnet.org>
> >>> a
> >>>>>> écrit :
> >>>>>>
> >>>>>>>
> >>>>>>> Le 28 déc. 2012 à 17:42, Jean-Louis Boudart <
> >>> jeanlouis.boudart@gmail.com>
> >>>>>>> a écrit :
> >>>>>>>
> >>>>>>>> Sounds good for me.
> >>>>>>>>
> >>>>>>>> But i'm wondering if it won't be safer to replace the step :
> >>>>>>>> * invoke ant install-all: it will put every plugins into a shared
> >>>>>>>> repository locally on the build machine
> >>>>>>>> by
> >>>>>>>> * invoke ant install-all: it will put every plugins into a staging
> >>>>>>>> repository on repo.easyant.org
> >>>>>>>>
> >>>>>>>> For the first release i agree that it doesn't change anything.
> >>>>>>>
> >>>>>>> The problem with that change is that only people having write
> access
> >>> to
> >>>>>>> repo.easyant.org could then build a distribution of easyant. We
> must
> >>> be
> >>>>>>> sure there is a simple enough process for people to build easyant
> from
> >>>>> the
> >>>>>>> sources.
> >>>>>>>
> >>>>>>>> But for future, plugins could be released individually. To make
> them
> >>>>>>>> accessible (as they will not be in the main distribution)
> >>>>>>>> repo.easyant.orgcould be a good host. Like for the main
> distribution,
> >>>>>>>> we could use a
> >>>>>>>> staging area to make them accessible before being definitivly
> >>> "public"
> >>>>>>> (or
> >>>>>>>> "stable").
> >>>>>>>>
> >>>>>>>> WDYT ?
> >>>>>>>
> >>>>>>> No objection. But we must make the difference between building a
> >>>>>>> distribution and releasing. Building a distribution should be
> >>> possible to
> >>>>>>> anyone having the sources. Making a release should then be
> building a
> >>>>>>> distribution but pushed onto Apache infra for the sources at
> least, or
> >>>>>>> somewhere else as repo.easyant.org for the binaries.
> >>>>>>>
> >>>>>>> Nicolas
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 2012/12/28 Nicolas Lalevée <ni...@hibnet.org>
> >>>>>>>>
> >>>>>>>>> So we have EasyAnt core, the end user executable, and the EasyAnt
> >>>>>>> plugins,
> >>>>>>>>> buildtypes and skeletons (the build.xml pieces) to release.
> >>>>>>>>>
> >>>>>>>>> All core and plugins have a build based on EasyAnt. Since this
> build
> >>>>>>> loop,
> >>>>>>>>> I have setup some very basic build.xml so we can bootstrap a
> first
> >>>>>>> release.
> >>>>>>>>>
> >>>>>>>>> Here is the process I am suggesting:
> >>>>>>>>> - in plugins, buildtypes and skeletons:
> >>>>>>>>> -- do a svn tag.
> >>>>>>>>> -- invoke ant distributions: it will build a
> >>> easyant-xxxx-0.9-src.zip
> >>>>>>>>> package to be publish in the release area
> >>>>>>>>> -- invoke ant install-all: it will put every plugins into a
> shared
> >>>>>>>>> repository locally on the build machine
> >>>>>>>>> - in core:
> >>>>>>>>> -- do a svn tag
> >>>>>>>>> -- invoke ant run -Dtarget=distribution: this is building
> easyant,
> >>> and
> >>>>>>>>> then running easyant with the plugins just installed in the
> shared
> >>>>>>> repo. At
> >>>>>>>>> the end we should have a easyant-core-0.9-bin.zip and a
> >>>>>>>>> easyant-core-0.9-src.zip ready to be published in the release
> area
> >>>>>>>>> - push the *-src.zip and *-bin.zip into the staging release area
> >>>>>>>>> - md5, sha1 and sign the zip files
> >>>>>>>>> - vote for the release
> >>>>>>>>>
> >>>>>>>>> Once the process released finished, the source of this 0.9 will
> be
> >>> then
> >>>>>>>>> available via 4 zip files. A zip distribution will be available
> to
> >>>>>>> download
> >>>>>>>>> for end user for immediate use.
> >>>>>>>>> And as an after release process, we would make the plugins,
> >>> buildtypes
> >>>>>>> and
> >>>>>>>>> skeletons available via our repository on repo.easyant.org.
> >>>>>>>>>
> >>>>>>>>> Does it sound good for everyone ?
> >>>>>>>>>
> >>>>>>>>> Nicolas
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Jean Louis Boudart
> >>>>>>>> Independent consultant
> >>>>>>>> Apache EasyAnt commiter http://incubator.apache.org/easyant/
> >>>>>>>
> >>>>>>>
> >>>>
> >>>
> >>>
> >
>
>
--
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://incubator.apache.org/easyant/
Re: A first release process
Posted by Nicolas Lalevée <ni...@hibnet.org>.
I had just a little trouble: the version should be 0.9-incubating.
What is the best way to make easyant core build to produce a distrib with that version ?
If the solution is to just rename the artifact afterwards, I don't mind, we can improve that later.
Nicolas
Le 25 janv. 2013 à 16:00, Nicolas Lalevée <ni...@hibnet.org> a écrit :
> Le 24 janv. 2013 à 21:23, Jean-Louis Boudart <je...@gmail.com> a écrit :
>
>> Ivy 2.3.0 release is almost ready, artifacts reached maven central repo.
>> Vote has ended without any veto. I assume official annouce is just a
>> question of time now.
>>
>> Could we start our release process now ? :p
>
> Definitively.
> I'll proceed soon, probably this week-end.
>
> Nicolas
>
>> Le 28 déc. 2012 22:53, "Nicolas Lalevée" <ni...@hibnet.org> a
>> écrit :
>>
>>>
>>> Le 28 déc. 2012 à 22:51, Nicolas Lalevée <ni...@hibnet.org> a
>>> écrit :
>>>
>>>>
>>>> Le 28 déc. 2012 à 22:05, Jean-Louis Boudart <je...@gmail.com>
>>> a écrit :
>>>>
>>>>> I was thinking about it this morning when i saw Maarten's mail.
>>>>> Are we supposed to make a RC ? or directly a release?
>>>>> If apache process forces us to make a RC, then we could do the release
>>> with
>>>>> current code base and then switch to 2.3.0-final.
>>>>
>>>> The ASF doesn't enforce anything about the quality of the code we are
>>> releasing. It is "just" about IP, License, PMC vote (IMPC in our case),
>>> source distribution and probably also the svn tagging. So we do what we
>>> want about versioning of releases.
>>>>
>>>>> In other case i would be in favor of waiting ivy 2.3.0 final release.
>>>>
>>>> So we'll release an EasyAnt 0.9 with Ivy 2.3.
>>>
>>> Actually this will be a 0.9-incubating, as per the Incubator rules.
>>>
>>> Nicolas
>>>
>>>>
>>>> Nicolas
>>>>
>>>>> By the way, does it sound good if I try do a release just after the
>>> release
>>>>> of Ivy 2.3.0 (so we can use it in EasyAnt) ? Ivy release process should
>>>>> start next week.
>>>>>
>>>>> Nicolas
>>>>>
>>>>> Le 28 déc. 2012 à 20:14, Jean-Louis Boudart <
>>> jeanlouis.boudart@gmail.com> a
>>>>> écrit :
>>>>>
>>>>>> Oki, maybe it's a premature discussion. Let's go as you described for
>>> the
>>>>>> first release and we will see in future how to enhance the process.
>>>>>>
>>>>>> So no objection for me :)
>>>>>> Le 28 déc. 2012 19:19, "Nicolas Lalevée" <ni...@hibnet.org>
>>> a
>>>>>> écrit :
>>>>>>
>>>>>>>
>>>>>>> Le 28 déc. 2012 à 17:42, Jean-Louis Boudart <
>>> jeanlouis.boudart@gmail.com>
>>>>>>> a écrit :
>>>>>>>
>>>>>>>> Sounds good for me.
>>>>>>>>
>>>>>>>> But i'm wondering if it won't be safer to replace the step :
>>>>>>>> * invoke ant install-all: it will put every plugins into a shared
>>>>>>>> repository locally on the build machine
>>>>>>>> by
>>>>>>>> * invoke ant install-all: it will put every plugins into a staging
>>>>>>>> repository on repo.easyant.org
>>>>>>>>
>>>>>>>> For the first release i agree that it doesn't change anything.
>>>>>>>
>>>>>>> The problem with that change is that only people having write access
>>> to
>>>>>>> repo.easyant.org could then build a distribution of easyant. We must
>>> be
>>>>>>> sure there is a simple enough process for people to build easyant from
>>>>> the
>>>>>>> sources.
>>>>>>>
>>>>>>>> But for future, plugins could be released individually. To make them
>>>>>>>> accessible (as they will not be in the main distribution)
>>>>>>>> repo.easyant.orgcould be a good host. Like for the main distribution,
>>>>>>>> we could use a
>>>>>>>> staging area to make them accessible before being definitivly
>>> "public"
>>>>>>> (or
>>>>>>>> "stable").
>>>>>>>>
>>>>>>>> WDYT ?
>>>>>>>
>>>>>>> No objection. But we must make the difference between building a
>>>>>>> distribution and releasing. Building a distribution should be
>>> possible to
>>>>>>> anyone having the sources. Making a release should then be building a
>>>>>>> distribution but pushed onto Apache infra for the sources at least, or
>>>>>>> somewhere else as repo.easyant.org for the binaries.
>>>>>>>
>>>>>>> Nicolas
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2012/12/28 Nicolas Lalevée <ni...@hibnet.org>
>>>>>>>>
>>>>>>>>> So we have EasyAnt core, the end user executable, and the EasyAnt
>>>>>>> plugins,
>>>>>>>>> buildtypes and skeletons (the build.xml pieces) to release.
>>>>>>>>>
>>>>>>>>> All core and plugins have a build based on EasyAnt. Since this build
>>>>>>> loop,
>>>>>>>>> I have setup some very basic build.xml so we can bootstrap a first
>>>>>>> release.
>>>>>>>>>
>>>>>>>>> Here is the process I am suggesting:
>>>>>>>>> - in plugins, buildtypes and skeletons:
>>>>>>>>> -- do a svn tag.
>>>>>>>>> -- invoke ant distributions: it will build a
>>> easyant-xxxx-0.9-src.zip
>>>>>>>>> package to be publish in the release area
>>>>>>>>> -- invoke ant install-all: it will put every plugins into a shared
>>>>>>>>> repository locally on the build machine
>>>>>>>>> - in core:
>>>>>>>>> -- do a svn tag
>>>>>>>>> -- invoke ant run -Dtarget=distribution: this is building easyant,
>>> and
>>>>>>>>> then running easyant with the plugins just installed in the shared
>>>>>>> repo. At
>>>>>>>>> the end we should have a easyant-core-0.9-bin.zip and a
>>>>>>>>> easyant-core-0.9-src.zip ready to be published in the release area
>>>>>>>>> - push the *-src.zip and *-bin.zip into the staging release area
>>>>>>>>> - md5, sha1 and sign the zip files
>>>>>>>>> - vote for the release
>>>>>>>>>
>>>>>>>>> Once the process released finished, the source of this 0.9 will be
>>> then
>>>>>>>>> available via 4 zip files. A zip distribution will be available to
>>>>>>> download
>>>>>>>>> for end user for immediate use.
>>>>>>>>> And as an after release process, we would make the plugins,
>>> buildtypes
>>>>>>> and
>>>>>>>>> skeletons available via our repository on repo.easyant.org.
>>>>>>>>>
>>>>>>>>> Does it sound good for everyone ?
>>>>>>>>>
>>>>>>>>> Nicolas
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Jean Louis Boudart
>>>>>>>> Independent consultant
>>>>>>>> Apache EasyAnt commiter http://incubator.apache.org/easyant/
>>>>>>>
>>>>>>>
>>>>
>>>
>>>
>
Re: A first release process
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le 24 janv. 2013 à 21:23, Jean-Louis Boudart <je...@gmail.com> a écrit :
> Ivy 2.3.0 release is almost ready, artifacts reached maven central repo.
> Vote has ended without any veto. I assume official annouce is just a
> question of time now.
>
> Could we start our release process now ? :p
Definitively.
I'll proceed soon, probably this week-end.
Nicolas
> Le 28 déc. 2012 22:53, "Nicolas Lalevée" <ni...@hibnet.org> a
> écrit :
>
>>
>> Le 28 déc. 2012 à 22:51, Nicolas Lalevée <ni...@hibnet.org> a
>> écrit :
>>
>>>
>>> Le 28 déc. 2012 à 22:05, Jean-Louis Boudart <je...@gmail.com>
>> a écrit :
>>>
>>>> I was thinking about it this morning when i saw Maarten's mail.
>>>> Are we supposed to make a RC ? or directly a release?
>>>> If apache process forces us to make a RC, then we could do the release
>> with
>>>> current code base and then switch to 2.3.0-final.
>>>
>>> The ASF doesn't enforce anything about the quality of the code we are
>> releasing. It is "just" about IP, License, PMC vote (IMPC in our case),
>> source distribution and probably also the svn tagging. So we do what we
>> want about versioning of releases.
>>>
>>>> In other case i would be in favor of waiting ivy 2.3.0 final release.
>>>
>>> So we'll release an EasyAnt 0.9 with Ivy 2.3.
>>
>> Actually this will be a 0.9-incubating, as per the Incubator rules.
>>
>> Nicolas
>>
>>>
>>> Nicolas
>>>
>>>> By the way, does it sound good if I try do a release just after the
>> release
>>>> of Ivy 2.3.0 (so we can use it in EasyAnt) ? Ivy release process should
>>>> start next week.
>>>>
>>>> Nicolas
>>>>
>>>> Le 28 déc. 2012 à 20:14, Jean-Louis Boudart <
>> jeanlouis.boudart@gmail.com> a
>>>> écrit :
>>>>
>>>>> Oki, maybe it's a premature discussion. Let's go as you described for
>> the
>>>>> first release and we will see in future how to enhance the process.
>>>>>
>>>>> So no objection for me :)
>>>>> Le 28 déc. 2012 19:19, "Nicolas Lalevée" <ni...@hibnet.org>
>> a
>>>>> écrit :
>>>>>
>>>>>>
>>>>>> Le 28 déc. 2012 à 17:42, Jean-Louis Boudart <
>> jeanlouis.boudart@gmail.com>
>>>>>> a écrit :
>>>>>>
>>>>>>> Sounds good for me.
>>>>>>>
>>>>>>> But i'm wondering if it won't be safer to replace the step :
>>>>>>> * invoke ant install-all: it will put every plugins into a shared
>>>>>>> repository locally on the build machine
>>>>>>> by
>>>>>>> * invoke ant install-all: it will put every plugins into a staging
>>>>>>> repository on repo.easyant.org
>>>>>>>
>>>>>>> For the first release i agree that it doesn't change anything.
>>>>>>
>>>>>> The problem with that change is that only people having write access
>> to
>>>>>> repo.easyant.org could then build a distribution of easyant. We must
>> be
>>>>>> sure there is a simple enough process for people to build easyant from
>>>> the
>>>>>> sources.
>>>>>>
>>>>>>> But for future, plugins could be released individually. To make them
>>>>>>> accessible (as they will not be in the main distribution)
>>>>>>> repo.easyant.orgcould be a good host. Like for the main distribution,
>>>>>>> we could use a
>>>>>>> staging area to make them accessible before being definitivly
>> "public"
>>>>>> (or
>>>>>>> "stable").
>>>>>>>
>>>>>>> WDYT ?
>>>>>>
>>>>>> No objection. But we must make the difference between building a
>>>>>> distribution and releasing. Building a distribution should be
>> possible to
>>>>>> anyone having the sources. Making a release should then be building a
>>>>>> distribution but pushed onto Apache infra for the sources at least, or
>>>>>> somewhere else as repo.easyant.org for the binaries.
>>>>>>
>>>>>> Nicolas
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2012/12/28 Nicolas Lalevée <ni...@hibnet.org>
>>>>>>>
>>>>>>>> So we have EasyAnt core, the end user executable, and the EasyAnt
>>>>>> plugins,
>>>>>>>> buildtypes and skeletons (the build.xml pieces) to release.
>>>>>>>>
>>>>>>>> All core and plugins have a build based on EasyAnt. Since this build
>>>>>> loop,
>>>>>>>> I have setup some very basic build.xml so we can bootstrap a first
>>>>>> release.
>>>>>>>>
>>>>>>>> Here is the process I am suggesting:
>>>>>>>> - in plugins, buildtypes and skeletons:
>>>>>>>> -- do a svn tag.
>>>>>>>> -- invoke ant distributions: it will build a
>> easyant-xxxx-0.9-src.zip
>>>>>>>> package to be publish in the release area
>>>>>>>> -- invoke ant install-all: it will put every plugins into a shared
>>>>>>>> repository locally on the build machine
>>>>>>>> - in core:
>>>>>>>> -- do a svn tag
>>>>>>>> -- invoke ant run -Dtarget=distribution: this is building easyant,
>> and
>>>>>>>> then running easyant with the plugins just installed in the shared
>>>>>> repo. At
>>>>>>>> the end we should have a easyant-core-0.9-bin.zip and a
>>>>>>>> easyant-core-0.9-src.zip ready to be published in the release area
>>>>>>>> - push the *-src.zip and *-bin.zip into the staging release area
>>>>>>>> - md5, sha1 and sign the zip files
>>>>>>>> - vote for the release
>>>>>>>>
>>>>>>>> Once the process released finished, the source of this 0.9 will be
>> then
>>>>>>>> available via 4 zip files. A zip distribution will be available to
>>>>>> download
>>>>>>>> for end user for immediate use.
>>>>>>>> And as an after release process, we would make the plugins,
>> buildtypes
>>>>>> and
>>>>>>>> skeletons available via our repository on repo.easyant.org.
>>>>>>>>
>>>>>>>> Does it sound good for everyone ?
>>>>>>>>
>>>>>>>> Nicolas
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Jean Louis Boudart
>>>>>>> Independent consultant
>>>>>>> Apache EasyAnt commiter http://incubator.apache.org/easyant/
>>>>>>
>>>>>>
>>>
>>
>>
Re: A first release process
Posted by Jean-Louis Boudart <je...@gmail.com>.
Ivy 2.3.0 release is almost ready, artifacts reached maven central repo.
Vote has ended without any veto. I assume official annouce is just a
question of time now.
Could we start our release process now ? :p
Le 28 déc. 2012 22:53, "Nicolas Lalevée" <ni...@hibnet.org> a
écrit :
>
> Le 28 déc. 2012 à 22:51, Nicolas Lalevée <ni...@hibnet.org> a
> écrit :
>
> >
> > Le 28 déc. 2012 à 22:05, Jean-Louis Boudart <je...@gmail.com>
> a écrit :
> >
> >> I was thinking about it this morning when i saw Maarten's mail.
> >> Are we supposed to make a RC ? or directly a release?
> >> If apache process forces us to make a RC, then we could do the release
> with
> >> current code base and then switch to 2.3.0-final.
> >
> > The ASF doesn't enforce anything about the quality of the code we are
> releasing. It is "just" about IP, License, PMC vote (IMPC in our case),
> source distribution and probably also the svn tagging. So we do what we
> want about versioning of releases.
> >
> >> In other case i would be in favor of waiting ivy 2.3.0 final release.
> >
> > So we'll release an EasyAnt 0.9 with Ivy 2.3.
>
> Actually this will be a 0.9-incubating, as per the Incubator rules.
>
> Nicolas
>
> >
> > Nicolas
> >
> >> By the way, does it sound good if I try do a release just after the
> release
> >> of Ivy 2.3.0 (so we can use it in EasyAnt) ? Ivy release process should
> >> start next week.
> >>
> >> Nicolas
> >>
> >> Le 28 déc. 2012 à 20:14, Jean-Louis Boudart <
> jeanlouis.boudart@gmail.com> a
> >> écrit :
> >>
> >>> Oki, maybe it's a premature discussion. Let's go as you described for
> the
> >>> first release and we will see in future how to enhance the process.
> >>>
> >>> So no objection for me :)
> >>> Le 28 déc. 2012 19:19, "Nicolas Lalevée" <ni...@hibnet.org>
> a
> >>> écrit :
> >>>
> >>>>
> >>>> Le 28 déc. 2012 à 17:42, Jean-Louis Boudart <
> jeanlouis.boudart@gmail.com>
> >>>> a écrit :
> >>>>
> >>>>> Sounds good for me.
> >>>>>
> >>>>> But i'm wondering if it won't be safer to replace the step :
> >>>>> * invoke ant install-all: it will put every plugins into a shared
> >>>>> repository locally on the build machine
> >>>>> by
> >>>>> * invoke ant install-all: it will put every plugins into a staging
> >>>>> repository on repo.easyant.org
> >>>>>
> >>>>> For the first release i agree that it doesn't change anything.
> >>>>
> >>>> The problem with that change is that only people having write access
> to
> >>>> repo.easyant.org could then build a distribution of easyant. We must
> be
> >>>> sure there is a simple enough process for people to build easyant from
> >> the
> >>>> sources.
> >>>>
> >>>>> But for future, plugins could be released individually. To make them
> >>>>> accessible (as they will not be in the main distribution)
> >>>>> repo.easyant.orgcould be a good host. Like for the main distribution,
> >>>>> we could use a
> >>>>> staging area to make them accessible before being definitivly
> "public"
> >>>> (or
> >>>>> "stable").
> >>>>>
> >>>>> WDYT ?
> >>>>
> >>>> No objection. But we must make the difference between building a
> >>>> distribution and releasing. Building a distribution should be
> possible to
> >>>> anyone having the sources. Making a release should then be building a
> >>>> distribution but pushed onto Apache infra for the sources at least, or
> >>>> somewhere else as repo.easyant.org for the binaries.
> >>>>
> >>>> Nicolas
> >>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> 2012/12/28 Nicolas Lalevée <ni...@hibnet.org>
> >>>>>
> >>>>>> So we have EasyAnt core, the end user executable, and the EasyAnt
> >>>> plugins,
> >>>>>> buildtypes and skeletons (the build.xml pieces) to release.
> >>>>>>
> >>>>>> All core and plugins have a build based on EasyAnt. Since this build
> >>>> loop,
> >>>>>> I have setup some very basic build.xml so we can bootstrap a first
> >>>> release.
> >>>>>>
> >>>>>> Here is the process I am suggesting:
> >>>>>> - in plugins, buildtypes and skeletons:
> >>>>>> -- do a svn tag.
> >>>>>> -- invoke ant distributions: it will build a
> easyant-xxxx-0.9-src.zip
> >>>>>> package to be publish in the release area
> >>>>>> -- invoke ant install-all: it will put every plugins into a shared
> >>>>>> repository locally on the build machine
> >>>>>> - in core:
> >>>>>> -- do a svn tag
> >>>>>> -- invoke ant run -Dtarget=distribution: this is building easyant,
> and
> >>>>>> then running easyant with the plugins just installed in the shared
> >>>> repo. At
> >>>>>> the end we should have a easyant-core-0.9-bin.zip and a
> >>>>>> easyant-core-0.9-src.zip ready to be published in the release area
> >>>>>> - push the *-src.zip and *-bin.zip into the staging release area
> >>>>>> - md5, sha1 and sign the zip files
> >>>>>> - vote for the release
> >>>>>>
> >>>>>> Once the process released finished, the source of this 0.9 will be
> then
> >>>>>> available via 4 zip files. A zip distribution will be available to
> >>>> download
> >>>>>> for end user for immediate use.
> >>>>>> And as an after release process, we would make the plugins,
> buildtypes
> >>>> and
> >>>>>> skeletons available via our repository on repo.easyant.org.
> >>>>>>
> >>>>>> Does it sound good for everyone ?
> >>>>>>
> >>>>>> Nicolas
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Jean Louis Boudart
> >>>>> Independent consultant
> >>>>> Apache EasyAnt commiter http://incubator.apache.org/easyant/
> >>>>
> >>>>
> >
>
>
Re: A first release process
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le 28 déc. 2012 à 22:51, Nicolas Lalevée <ni...@hibnet.org> a écrit :
>
> Le 28 déc. 2012 à 22:05, Jean-Louis Boudart <je...@gmail.com> a écrit :
>
>> I was thinking about it this morning when i saw Maarten's mail.
>> Are we supposed to make a RC ? or directly a release?
>> If apache process forces us to make a RC, then we could do the release with
>> current code base and then switch to 2.3.0-final.
>
> The ASF doesn't enforce anything about the quality of the code we are releasing. It is "just" about IP, License, PMC vote (IMPC in our case), source distribution and probably also the svn tagging. So we do what we want about versioning of releases.
>
>> In other case i would be in favor of waiting ivy 2.3.0 final release.
>
> So we'll release an EasyAnt 0.9 with Ivy 2.3.
Actually this will be a 0.9-incubating, as per the Incubator rules.
Nicolas
>
> Nicolas
>
>> By the way, does it sound good if I try do a release just after the release
>> of Ivy 2.3.0 (so we can use it in EasyAnt) ? Ivy release process should
>> start next week.
>>
>> Nicolas
>>
>> Le 28 déc. 2012 à 20:14, Jean-Louis Boudart <je...@gmail.com> a
>> écrit :
>>
>>> Oki, maybe it's a premature discussion. Let's go as you described for the
>>> first release and we will see in future how to enhance the process.
>>>
>>> So no objection for me :)
>>> Le 28 déc. 2012 19:19, "Nicolas Lalevée" <ni...@hibnet.org> a
>>> écrit :
>>>
>>>>
>>>> Le 28 déc. 2012 à 17:42, Jean-Louis Boudart <je...@gmail.com>
>>>> a écrit :
>>>>
>>>>> Sounds good for me.
>>>>>
>>>>> But i'm wondering if it won't be safer to replace the step :
>>>>> * invoke ant install-all: it will put every plugins into a shared
>>>>> repository locally on the build machine
>>>>> by
>>>>> * invoke ant install-all: it will put every plugins into a staging
>>>>> repository on repo.easyant.org
>>>>>
>>>>> For the first release i agree that it doesn't change anything.
>>>>
>>>> The problem with that change is that only people having write access to
>>>> repo.easyant.org could then build a distribution of easyant. We must be
>>>> sure there is a simple enough process for people to build easyant from
>> the
>>>> sources.
>>>>
>>>>> But for future, plugins could be released individually. To make them
>>>>> accessible (as they will not be in the main distribution)
>>>>> repo.easyant.orgcould be a good host. Like for the main distribution,
>>>>> we could use a
>>>>> staging area to make them accessible before being definitivly "public"
>>>> (or
>>>>> "stable").
>>>>>
>>>>> WDYT ?
>>>>
>>>> No objection. But we must make the difference between building a
>>>> distribution and releasing. Building a distribution should be possible to
>>>> anyone having the sources. Making a release should then be building a
>>>> distribution but pushed onto Apache infra for the sources at least, or
>>>> somewhere else as repo.easyant.org for the binaries.
>>>>
>>>> Nicolas
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2012/12/28 Nicolas Lalevée <ni...@hibnet.org>
>>>>>
>>>>>> So we have EasyAnt core, the end user executable, and the EasyAnt
>>>> plugins,
>>>>>> buildtypes and skeletons (the build.xml pieces) to release.
>>>>>>
>>>>>> All core and plugins have a build based on EasyAnt. Since this build
>>>> loop,
>>>>>> I have setup some very basic build.xml so we can bootstrap a first
>>>> release.
>>>>>>
>>>>>> Here is the process I am suggesting:
>>>>>> - in plugins, buildtypes and skeletons:
>>>>>> -- do a svn tag.
>>>>>> -- invoke ant distributions: it will build a easyant-xxxx-0.9-src.zip
>>>>>> package to be publish in the release area
>>>>>> -- invoke ant install-all: it will put every plugins into a shared
>>>>>> repository locally on the build machine
>>>>>> - in core:
>>>>>> -- do a svn tag
>>>>>> -- invoke ant run -Dtarget=distribution: this is building easyant, and
>>>>>> then running easyant with the plugins just installed in the shared
>>>> repo. At
>>>>>> the end we should have a easyant-core-0.9-bin.zip and a
>>>>>> easyant-core-0.9-src.zip ready to be published in the release area
>>>>>> - push the *-src.zip and *-bin.zip into the staging release area
>>>>>> - md5, sha1 and sign the zip files
>>>>>> - vote for the release
>>>>>>
>>>>>> Once the process released finished, the source of this 0.9 will be then
>>>>>> available via 4 zip files. A zip distribution will be available to
>>>> download
>>>>>> for end user for immediate use.
>>>>>> And as an after release process, we would make the plugins, buildtypes
>>>> and
>>>>>> skeletons available via our repository on repo.easyant.org.
>>>>>>
>>>>>> Does it sound good for everyone ?
>>>>>>
>>>>>> Nicolas
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jean Louis Boudart
>>>>> Independent consultant
>>>>> Apache EasyAnt commiter http://incubator.apache.org/easyant/
>>>>
>>>>
>
Re: A first release process
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le 28 déc. 2012 à 22:05, Jean-Louis Boudart <je...@gmail.com> a écrit :
> I was thinking about it this morning when i saw Maarten's mail.
> Are we supposed to make a RC ? or directly a release?
> If apache process forces us to make a RC, then we could do the release with
> current code base and then switch to 2.3.0-final.
The ASF doesn't enforce anything about the quality of the code we are releasing. It is "just" about IP, License, PMC vote (IMPC in our case), source distribution and probably also the svn tagging. So we do what we want about versioning of releases.
> In other case i would be in favor of waiting ivy 2.3.0 final release.
So we'll release an EasyAnt 0.9 with Ivy 2.3.
Nicolas
> By the way, does it sound good if I try do a release just after the release
> of Ivy 2.3.0 (so we can use it in EasyAnt) ? Ivy release process should
> start next week.
>
> Nicolas
>
> Le 28 déc. 2012 à 20:14, Jean-Louis Boudart <je...@gmail.com> a
> écrit :
>
>> Oki, maybe it's a premature discussion. Let's go as you described for the
>> first release and we will see in future how to enhance the process.
>>
>> So no objection for me :)
>> Le 28 déc. 2012 19:19, "Nicolas Lalevée" <ni...@hibnet.org> a
>> écrit :
>>
>>>
>>> Le 28 déc. 2012 à 17:42, Jean-Louis Boudart <je...@gmail.com>
>>> a écrit :
>>>
>>>> Sounds good for me.
>>>>
>>>> But i'm wondering if it won't be safer to replace the step :
>>>> * invoke ant install-all: it will put every plugins into a shared
>>>> repository locally on the build machine
>>>> by
>>>> * invoke ant install-all: it will put every plugins into a staging
>>>> repository on repo.easyant.org
>>>>
>>>> For the first release i agree that it doesn't change anything.
>>>
>>> The problem with that change is that only people having write access to
>>> repo.easyant.org could then build a distribution of easyant. We must be
>>> sure there is a simple enough process for people to build easyant from
> the
>>> sources.
>>>
>>>> But for future, plugins could be released individually. To make them
>>>> accessible (as they will not be in the main distribution)
>>>> repo.easyant.orgcould be a good host. Like for the main distribution,
>>>> we could use a
>>>> staging area to make them accessible before being definitivly "public"
>>> (or
>>>> "stable").
>>>>
>>>> WDYT ?
>>>
>>> No objection. But we must make the difference between building a
>>> distribution and releasing. Building a distribution should be possible to
>>> anyone having the sources. Making a release should then be building a
>>> distribution but pushed onto Apache infra for the sources at least, or
>>> somewhere else as repo.easyant.org for the binaries.
>>>
>>> Nicolas
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 2012/12/28 Nicolas Lalevée <ni...@hibnet.org>
>>>>
>>>>> So we have EasyAnt core, the end user executable, and the EasyAnt
>>> plugins,
>>>>> buildtypes and skeletons (the build.xml pieces) to release.
>>>>>
>>>>> All core and plugins have a build based on EasyAnt. Since this build
>>> loop,
>>>>> I have setup some very basic build.xml so we can bootstrap a first
>>> release.
>>>>>
>>>>> Here is the process I am suggesting:
>>>>> - in plugins, buildtypes and skeletons:
>>>>> -- do a svn tag.
>>>>> -- invoke ant distributions: it will build a easyant-xxxx-0.9-src.zip
>>>>> package to be publish in the release area
>>>>> -- invoke ant install-all: it will put every plugins into a shared
>>>>> repository locally on the build machine
>>>>> - in core:
>>>>> -- do a svn tag
>>>>> -- invoke ant run -Dtarget=distribution: this is building easyant, and
>>>>> then running easyant with the plugins just installed in the shared
>>> repo. At
>>>>> the end we should have a easyant-core-0.9-bin.zip and a
>>>>> easyant-core-0.9-src.zip ready to be published in the release area
>>>>> - push the *-src.zip and *-bin.zip into the staging release area
>>>>> - md5, sha1 and sign the zip files
>>>>> - vote for the release
>>>>>
>>>>> Once the process released finished, the source of this 0.9 will be then
>>>>> available via 4 zip files. A zip distribution will be available to
>>> download
>>>>> for end user for immediate use.
>>>>> And as an after release process, we would make the plugins, buildtypes
>>> and
>>>>> skeletons available via our repository on repo.easyant.org.
>>>>>
>>>>> Does it sound good for everyone ?
>>>>>
>>>>> Nicolas
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Jean Louis Boudart
>>>> Independent consultant
>>>> Apache EasyAnt commiter http://incubator.apache.org/easyant/
>>>
>>>
Re: A first release process
Posted by Jean-Louis Boudart <je...@gmail.com>.
I was thinking about it this morning when i saw Maarten's mail.
Are we supposed to make a RC ? or directly a release?
If apache process forces us to make a RC, then we could do the release with
current code base and then switch to 2.3.0-final.
In other case i would be in favor of waiting ivy 2.3.0 final release.
By the way, does it sound good if I try do a release just after the release
of Ivy 2.3.0 (so we can use it in EasyAnt) ? Ivy release process should
start next week.
Nicolas
Le 28 déc. 2012 à 20:14, Jean-Louis Boudart <je...@gmail.com> a
écrit :
> Oki, maybe it's a premature discussion. Let's go as you described for the
> first release and we will see in future how to enhance the process.
>
> So no objection for me :)
> Le 28 déc. 2012 19:19, "Nicolas Lalevée" <ni...@hibnet.org> a
> écrit :
>
>>
>> Le 28 déc. 2012 à 17:42, Jean-Louis Boudart <je...@gmail.com>
>> a écrit :
>>
>>> Sounds good for me.
>>>
>>> But i'm wondering if it won't be safer to replace the step :
>>> * invoke ant install-all: it will put every plugins into a shared
>>> repository locally on the build machine
>>> by
>>> * invoke ant install-all: it will put every plugins into a staging
>>> repository on repo.easyant.org
>>>
>>> For the first release i agree that it doesn't change anything.
>>
>> The problem with that change is that only people having write access to
>> repo.easyant.org could then build a distribution of easyant. We must be
>> sure there is a simple enough process for people to build easyant from
the
>> sources.
>>
>>> But for future, plugins could be released individually. To make them
>>> accessible (as they will not be in the main distribution)
>>> repo.easyant.orgcould be a good host. Like for the main distribution,
>>> we could use a
>>> staging area to make them accessible before being definitivly "public"
>> (or
>>> "stable").
>>>
>>> WDYT ?
>>
>> No objection. But we must make the difference between building a
>> distribution and releasing. Building a distribution should be possible to
>> anyone having the sources. Making a release should then be building a
>> distribution but pushed onto Apache infra for the sources at least, or
>> somewhere else as repo.easyant.org for the binaries.
>>
>> Nicolas
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 2012/12/28 Nicolas Lalevée <ni...@hibnet.org>
>>>
>>>> So we have EasyAnt core, the end user executable, and the EasyAnt
>> plugins,
>>>> buildtypes and skeletons (the build.xml pieces) to release.
>>>>
>>>> All core and plugins have a build based on EasyAnt. Since this build
>> loop,
>>>> I have setup some very basic build.xml so we can bootstrap a first
>> release.
>>>>
>>>> Here is the process I am suggesting:
>>>> - in plugins, buildtypes and skeletons:
>>>> -- do a svn tag.
>>>> -- invoke ant distributions: it will build a easyant-xxxx-0.9-src.zip
>>>> package to be publish in the release area
>>>> -- invoke ant install-all: it will put every plugins into a shared
>>>> repository locally on the build machine
>>>> - in core:
>>>> -- do a svn tag
>>>> -- invoke ant run -Dtarget=distribution: this is building easyant, and
>>>> then running easyant with the plugins just installed in the shared
>> repo. At
>>>> the end we should have a easyant-core-0.9-bin.zip and a
>>>> easyant-core-0.9-src.zip ready to be published in the release area
>>>> - push the *-src.zip and *-bin.zip into the staging release area
>>>> - md5, sha1 and sign the zip files
>>>> - vote for the release
>>>>
>>>> Once the process released finished, the source of this 0.9 will be then
>>>> available via 4 zip files. A zip distribution will be available to
>> download
>>>> for end user for immediate use.
>>>> And as an after release process, we would make the plugins, buildtypes
>> and
>>>> skeletons available via our repository on repo.easyant.org.
>>>>
>>>> Does it sound good for everyone ?
>>>>
>>>> Nicolas
>>>>
>>>>
>>>
>>>
>>> --
>>> Jean Louis Boudart
>>> Independent consultant
>>> Apache EasyAnt commiter http://incubator.apache.org/easyant/
>>
>>
Re: A first release process
Posted by Nicolas Lalevée <ni...@hibnet.org>.
By the way, does it sound good if I try do a release just after the release of Ivy 2.3.0 (so we can use it in EasyAnt) ? Ivy release process should start next week.
Nicolas
Le 28 déc. 2012 à 20:14, Jean-Louis Boudart <je...@gmail.com> a écrit :
> Oki, maybe it's a premature discussion. Let's go as you described for the
> first release and we will see in future how to enhance the process.
>
> So no objection for me :)
> Le 28 déc. 2012 19:19, "Nicolas Lalevée" <ni...@hibnet.org> a
> écrit :
>
>>
>> Le 28 déc. 2012 à 17:42, Jean-Louis Boudart <je...@gmail.com>
>> a écrit :
>>
>>> Sounds good for me.
>>>
>>> But i'm wondering if it won't be safer to replace the step :
>>> * invoke ant install-all: it will put every plugins into a shared
>>> repository locally on the build machine
>>> by
>>> * invoke ant install-all: it will put every plugins into a staging
>>> repository on repo.easyant.org
>>>
>>> For the first release i agree that it doesn't change anything.
>>
>> The problem with that change is that only people having write access to
>> repo.easyant.org could then build a distribution of easyant. We must be
>> sure there is a simple enough process for people to build easyant from the
>> sources.
>>
>>> But for future, plugins could be released individually. To make them
>>> accessible (as they will not be in the main distribution)
>>> repo.easyant.orgcould be a good host. Like for the main distribution,
>>> we could use a
>>> staging area to make them accessible before being definitivly "public"
>> (or
>>> "stable").
>>>
>>> WDYT ?
>>
>> No objection. But we must make the difference between building a
>> distribution and releasing. Building a distribution should be possible to
>> anyone having the sources. Making a release should then be building a
>> distribution but pushed onto Apache infra for the sources at least, or
>> somewhere else as repo.easyant.org for the binaries.
>>
>> Nicolas
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 2012/12/28 Nicolas Lalevée <ni...@hibnet.org>
>>>
>>>> So we have EasyAnt core, the end user executable, and the EasyAnt
>> plugins,
>>>> buildtypes and skeletons (the build.xml pieces) to release.
>>>>
>>>> All core and plugins have a build based on EasyAnt. Since this build
>> loop,
>>>> I have setup some very basic build.xml so we can bootstrap a first
>> release.
>>>>
>>>> Here is the process I am suggesting:
>>>> - in plugins, buildtypes and skeletons:
>>>> -- do a svn tag.
>>>> -- invoke ant distributions: it will build a easyant-xxxx-0.9-src.zip
>>>> package to be publish in the release area
>>>> -- invoke ant install-all: it will put every plugins into a shared
>>>> repository locally on the build machine
>>>> - in core:
>>>> -- do a svn tag
>>>> -- invoke ant run -Dtarget=distribution: this is building easyant, and
>>>> then running easyant with the plugins just installed in the shared
>> repo. At
>>>> the end we should have a easyant-core-0.9-bin.zip and a
>>>> easyant-core-0.9-src.zip ready to be published in the release area
>>>> - push the *-src.zip and *-bin.zip into the staging release area
>>>> - md5, sha1 and sign the zip files
>>>> - vote for the release
>>>>
>>>> Once the process released finished, the source of this 0.9 will be then
>>>> available via 4 zip files. A zip distribution will be available to
>> download
>>>> for end user for immediate use.
>>>> And as an after release process, we would make the plugins, buildtypes
>> and
>>>> skeletons available via our repository on repo.easyant.org.
>>>>
>>>> Does it sound good for everyone ?
>>>>
>>>> Nicolas
>>>>
>>>>
>>>
>>>
>>> --
>>> Jean Louis Boudart
>>> Independent consultant
>>> Apache EasyAnt commiter http://incubator.apache.org/easyant/
>>
>>
Re: A first release process
Posted by Jean-Louis Boudart <je...@gmail.com>.
Oki, maybe it's a premature discussion. Let's go as you described for the
first release and we will see in future how to enhance the process.
So no objection for me :)
Le 28 déc. 2012 19:19, "Nicolas Lalevée" <ni...@hibnet.org> a
écrit :
>
> Le 28 déc. 2012 à 17:42, Jean-Louis Boudart <je...@gmail.com>
> a écrit :
>
> > Sounds good for me.
> >
> > But i'm wondering if it won't be safer to replace the step :
> > * invoke ant install-all: it will put every plugins into a shared
> > repository locally on the build machine
> > by
> > * invoke ant install-all: it will put every plugins into a staging
> > repository on repo.easyant.org
> >
> > For the first release i agree that it doesn't change anything.
>
> The problem with that change is that only people having write access to
> repo.easyant.org could then build a distribution of easyant. We must be
> sure there is a simple enough process for people to build easyant from the
> sources.
>
> > But for future, plugins could be released individually. To make them
> > accessible (as they will not be in the main distribution)
> > repo.easyant.orgcould be a good host. Like for the main distribution,
> > we could use a
> > staging area to make them accessible before being definitivly "public"
> (or
> > "stable").
> >
> > WDYT ?
>
> No objection. But we must make the difference between building a
> distribution and releasing. Building a distribution should be possible to
> anyone having the sources. Making a release should then be building a
> distribution but pushed onto Apache infra for the sources at least, or
> somewhere else as repo.easyant.org for the binaries.
>
> Nicolas
>
> >
> >
> >
> >
> >
> >
> >
> > 2012/12/28 Nicolas Lalevée <ni...@hibnet.org>
> >
> >> So we have EasyAnt core, the end user executable, and the EasyAnt
> plugins,
> >> buildtypes and skeletons (the build.xml pieces) to release.
> >>
> >> All core and plugins have a build based on EasyAnt. Since this build
> loop,
> >> I have setup some very basic build.xml so we can bootstrap a first
> release.
> >>
> >> Here is the process I am suggesting:
> >> - in plugins, buildtypes and skeletons:
> >> -- do a svn tag.
> >> -- invoke ant distributions: it will build a easyant-xxxx-0.9-src.zip
> >> package to be publish in the release area
> >> -- invoke ant install-all: it will put every plugins into a shared
> >> repository locally on the build machine
> >> - in core:
> >> -- do a svn tag
> >> -- invoke ant run -Dtarget=distribution: this is building easyant, and
> >> then running easyant with the plugins just installed in the shared
> repo. At
> >> the end we should have a easyant-core-0.9-bin.zip and a
> >> easyant-core-0.9-src.zip ready to be published in the release area
> >> - push the *-src.zip and *-bin.zip into the staging release area
> >> - md5, sha1 and sign the zip files
> >> - vote for the release
> >>
> >> Once the process released finished, the source of this 0.9 will be then
> >> available via 4 zip files. A zip distribution will be available to
> download
> >> for end user for immediate use.
> >> And as an after release process, we would make the plugins, buildtypes
> and
> >> skeletons available via our repository on repo.easyant.org.
> >>
> >> Does it sound good for everyone ?
> >>
> >> Nicolas
> >>
> >>
> >
> >
> > --
> > Jean Louis Boudart
> > Independent consultant
> > Apache EasyAnt commiter http://incubator.apache.org/easyant/
>
>
Re: A first release process
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Le 28 déc. 2012 à 17:42, Jean-Louis Boudart <je...@gmail.com> a écrit :
> Sounds good for me.
>
> But i'm wondering if it won't be safer to replace the step :
> * invoke ant install-all: it will put every plugins into a shared
> repository locally on the build machine
> by
> * invoke ant install-all: it will put every plugins into a staging
> repository on repo.easyant.org
>
> For the first release i agree that it doesn't change anything.
The problem with that change is that only people having write access to repo.easyant.org could then build a distribution of easyant. We must be sure there is a simple enough process for people to build easyant from the sources.
> But for future, plugins could be released individually. To make them
> accessible (as they will not be in the main distribution)
> repo.easyant.orgcould be a good host. Like for the main distribution,
> we could use a
> staging area to make them accessible before being definitivly "public" (or
> "stable").
>
> WDYT ?
No objection. But we must make the difference between building a distribution and releasing. Building a distribution should be possible to anyone having the sources. Making a release should then be building a distribution but pushed onto Apache infra for the sources at least, or somewhere else as repo.easyant.org for the binaries.
Nicolas
>
>
>
>
>
>
>
> 2012/12/28 Nicolas Lalevée <ni...@hibnet.org>
>
>> So we have EasyAnt core, the end user executable, and the EasyAnt plugins,
>> buildtypes and skeletons (the build.xml pieces) to release.
>>
>> All core and plugins have a build based on EasyAnt. Since this build loop,
>> I have setup some very basic build.xml so we can bootstrap a first release.
>>
>> Here is the process I am suggesting:
>> - in plugins, buildtypes and skeletons:
>> -- do a svn tag.
>> -- invoke ant distributions: it will build a easyant-xxxx-0.9-src.zip
>> package to be publish in the release area
>> -- invoke ant install-all: it will put every plugins into a shared
>> repository locally on the build machine
>> - in core:
>> -- do a svn tag
>> -- invoke ant run -Dtarget=distribution: this is building easyant, and
>> then running easyant with the plugins just installed in the shared repo. At
>> the end we should have a easyant-core-0.9-bin.zip and a
>> easyant-core-0.9-src.zip ready to be published in the release area
>> - push the *-src.zip and *-bin.zip into the staging release area
>> - md5, sha1 and sign the zip files
>> - vote for the release
>>
>> Once the process released finished, the source of this 0.9 will be then
>> available via 4 zip files. A zip distribution will be available to download
>> for end user for immediate use.
>> And as an after release process, we would make the plugins, buildtypes and
>> skeletons available via our repository on repo.easyant.org.
>>
>> Does it sound good for everyone ?
>>
>> Nicolas
>>
>>
>
>
> --
> Jean Louis Boudart
> Independent consultant
> Apache EasyAnt commiter http://incubator.apache.org/easyant/
Re: A first release process
Posted by Jean-Louis Boudart <je...@gmail.com>.
Sounds good for me.
But i'm wondering if it won't be safer to replace the step :
* invoke ant install-all: it will put every plugins into a shared
repository locally on the build machine
by
* invoke ant install-all: it will put every plugins into a staging
repository on repo.easyant.org
For the first release i agree that it doesn't change anything.
But for future, plugins could be released individually. To make them
accessible (as they will not be in the main distribution)
repo.easyant.orgcould be a good host. Like for the main distribution,
we could use a
staging area to make them accessible before being definitivly "public" (or
"stable").
WDYT ?
2012/12/28 Nicolas Lalevée <ni...@hibnet.org>
> So we have EasyAnt core, the end user executable, and the EasyAnt plugins,
> buildtypes and skeletons (the build.xml pieces) to release.
>
> All core and plugins have a build based on EasyAnt. Since this build loop,
> I have setup some very basic build.xml so we can bootstrap a first release.
>
> Here is the process I am suggesting:
> - in plugins, buildtypes and skeletons:
> -- do a svn tag.
> -- invoke ant distributions: it will build a easyant-xxxx-0.9-src.zip
> package to be publish in the release area
> -- invoke ant install-all: it will put every plugins into a shared
> repository locally on the build machine
> - in core:
> -- do a svn tag
> -- invoke ant run -Dtarget=distribution: this is building easyant, and
> then running easyant with the plugins just installed in the shared repo. At
> the end we should have a easyant-core-0.9-bin.zip and a
> easyant-core-0.9-src.zip ready to be published in the release area
> - push the *-src.zip and *-bin.zip into the staging release area
> - md5, sha1 and sign the zip files
> - vote for the release
>
> Once the process released finished, the source of this 0.9 will be then
> available via 4 zip files. A zip distribution will be available to download
> for end user for immediate use.
> And as an after release process, we would make the plugins, buildtypes and
> skeletons available via our repository on repo.easyant.org.
>
> Does it sound good for everyone ?
>
> Nicolas
>
>
--
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://incubator.apache.org/easyant/