incubator-easyant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Louis Boudart <jeanlouis.boud...@gmail.com>
Subject Re: A first release process
Date Fri, 01 Mar 2013 23:46:18 GMT
Issue seems to came from how xooki.dir is located :
 [generate] script file ./xooki/xooki.js is not found
 [generate] Result: 11

An issue with basedir ? A bug in xooki plugin ?

I found a workarroud (copy xooki in current directory and set basedir
property to `pwd`). I succeed to generate the website.

Everything is online ;)


2013/3/1 Jean-Louis Boudart <jeanlouis.boudart@gmail.com>

> I've udpated the download page, but i'm getting errors while generating.
> Could you try on your side ?
>  Le 27 févr. 2013 23:06, "Nicolas Lalevée" <nicolas.lalevee@hibnet.org> a
> écrit :
>
> 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 <jeanlouis.boudart@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 <jeanlouis.boudart@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 <nicolas.lalevee@hibnet.org>
>> >>
>> >>> Le 28 janv. 2013 à 10:16, Jean-Louis Boudart <
>> jeanlouis.boudart@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 <nicolas.lalevee@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 <
>> nicolas.lalevee@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" <
>> nicolas.lalevee@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
<nicolas.lalevee@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/
>>
>>


-- 
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://incubator.apache.org/easyant/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message