You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@excalibur.apache.org by Vadim Gritsenko <va...@reverycodes.com> on 2005/04/07 15:47:39 UTC
Release excalibur-logger, -pool, -component...
Hi All,
I'd like to get some excalibur components released. There are couple of reasons
for that, one is bugfixes applied to trunk, and another is that releases which
are out there compiled with jdk 1.4 (instead of 1.3), and due to the fact that I
do not see any tags in SVN (neither do know what revision number was used to
build component releases), I think it's easier to make a bugfix release with a
tag then to make attempts to find proper revision to do a re-builds.
WDYT?
Thanks,
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Excalibur Release Plan
Posted by "Sasvata (Shash) Chatterjee" <sh...@badfw.org>.
>I hope we can get rid of this. jisp 2.5.1 is buggy and we cannot upgrade
>to newer version, since they are GPL-ed.
>
>
>
I don't have the source here at work, I'll check tonight.
>There is hsqldb 1.7.3.3. If somebody points me where is the code, I can
>try to fix this. ;-)
>
>
>
It was in excalibur datasource (I was running on XP), it had to with
lock on the DB not being released...I'll post tonight
>>log4j - 1.2.8
>>
>>
>
>1.2.9 (near the same as 1.2.8, but why not?). ;-)
>
>
>>xalan - 2.6.0
>>
>>
>
>Depending of the level of dependency, I will suggest here an CVS version.
>We needed to updated this lib in cocoon too.
>
>
>
>>xerces - 2.4.0
>>
>>
>
>there is 2.6.2.
>
>
>
>>xml-apis - 2.0.2
>>
>>
>
>Same as xalan.
>
>
I don't see any of these at ibiblio, I was putting in the latest JARs
I found there. We can probably put in these JARs on the excalibur
repo., but I would guess that we don't want to be in the JAR/repo
management business if we can avoid it (what do others think about
this?). Maybe you can post on the respective mailing-lists and see if
they'll upload to ibiblio?
Shash
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Datasource test failure with HsqlDB-1.7.3.0 (was: Re: Excalibur Release
Plan)
Posted by Shash Chatterjee <sh...@badfw.org>.
Antonio,
>There is hsqldb 1.7.3.3. If somebody points me where is the code, I can
>try to fix this. ;-)
>
>
http://issues.apache.org/jira/browse/EXLBR-22
Shash
Re: Excalibur Release Plan (was: Re: Release excalibur-logger,
-pool, -component.)
Posted by Antonio Gallardo <ag...@agssa.net>.
On Dom, 10 de Abril de 2005, 14:04, Shash Chatterjee dijo:
Related to newer (updated) libs:
> jisp - 2.5.1
I hope we can get rid of this. jisp 2.5.1 is buggy and we cannot upgrade
to newer version, since they are GPL-ed.
> junit - 3.8.1
> juintperf - 1.8.1
> hsqldb - 1.7.1 (1.7.3 causes test failure...need to chase)
There is hsqldb 1.7.3.3. If somebody points me where is the code, I can
try to fix this. ;-)
> log4j - 1.2.8
1.2.9 (near the same as 1.2.8, but why not?). ;-)
> qdox - 1.5
> servletapi - 2.3
> xalan - 2.6.0
Depending of the level of dependency, I will suggest here an CVS version.
We needed to updated this lib in cocoon too.
> xerces - 2.4.0
there is 2.6.2.
> xml-apis - 2.0.2
Same as xalan.
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Excalibur Release Plan
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Leo Simons wrote:
> Summary:
>
> I advise to keep the number of versions to track and the number of
> independent components to release down to a sensible level. Don't try to
> "get it right", but aim for "some sort of useful, understandable and
> consistent versioning".
Are you suggesting to sync up all the versions? :) You'd have to label trunk
just once then :)
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Excalibur Release Plan
Posted by "Sasvata (Shash) Chatterjee" <sh...@badfw.org>.
Leo,
>There's three ways to do version management, the right way, the wrong way,
>and the army way. Or something like that :-D
>
>Versioning is a *hard* problem to get right. Being consistent at getting it
>right is even harder, and as soon as you start being inconsistent meaning of
>version numbers beyond "bigger as the previous one" quickly starts going
>away.
>
>What version of excalibur-datasource is compatible with what version of
>excalibur-instrument? Can I use fortress-container-api v1.1.4 with
>fortress-container-impl v1.2.1?
>
>Historically we've never managed to get it quite right, despite trying
>really really hard a few times. Reducing the number of versions and just
>synchronizing them (like GNOME and affiliated projects do for example) might
>seem silly, but it is a lot easier to get right.
>
>Releasing all fortress jars with a new version number, knowing those
>released jars are mutually compatible, is a lot easier than figuring out
>that you need api version 1.1.4 with implementation 1.2.1, but 1.1.3 with
>implemention 1.2.0. Especially three years from now. You've just witnessed
>the horror it currently is to answer questions like that ;-)
>
>
>
I have seen it done both ways, and there are pros/cons as with all
practical things. The pro on more granular versioning is of course,
only what changes gets released. The con of course, as you say, is
correlating everything. But, I do agree, that it is simpler to release
related JARs together in the interest of keeping things simple to follow.
>When porting excalibur to svn, we made the decision to reduce the number of
>versions we keep track of. I tried to identify a few "groups" that might
>make sense to version seperately so it wasn't a really big shock at first.
>
>
>
This comment was related to tagging the entire trunk or not, if we were
going to tag only components, then the problem was determining what tag
the project-common.xml would fall under. But, if we are tagging the
entire trunk, this is a moot point, everything gets the same tag.
>I strongly recommend keeping it that way (even if just to keep sane), or if
>changing it, changing it in the *other* direction (less seperately tracked
>versions, not more).
>
In my release plan, I think I may have proposed that some components
have different version numbers than nthis would allow. I'll go back and
make sure Fortress, instrumentation, fw, components (+deprecated), and
cornerstone are the "groups" and everything within a group has the same
version. Sound OK?
>
>Having a project-common.xml is a simple and common way to keep common
>metadata common, but any alternatives are all fine with me, as long as it
>works.
>
>
>
>What a rant. Sorry!
>
>
No problem. Now, seriously, how do you really feel about versioning
everything on it's own?
:-)
Shash
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Excalibur Release Plan
Posted by Leo Simons <ma...@leosimons.com>.
> I am wondering if our svn structure is really suited
> to the sub-project level releases, and tagging, we want to do? Somebody
> help me out here....this is not a rhetorical question :-).
I think I just answered that in my previous email :-)
> We could tag the entire repo for each sub-project release and tag, but
> that seems sheer overkill to me. Since we haven't tagged yet, this
> might be a good time to rearrange the repo as we need, once and for all.
It's not overkill. That's your CVS training sneaking up on ya ;) It takes
just a few bytes in the repository to do the tag, just a single svn command
to run, and it is a lot easier to manage than several dozen trunks.
The guidelines about trunk-per-project are more suited for less "granular"
projects. Us java people with our many tiny component jars would get mad
easily enough. Imagine how to get a sensible build tree for multiproject
builds...
> I hadn't thought about buildsystem actually. Take cornerstone for
> example. there is a trunk/cornerstone/project-common.xml, that defines
> the currentVersion as "1.2". In this case all the cornerstone
> components are actuall being released as 1.2, so no problem. Let's say
> we make a bug fix to sockets-impl...making it 1.2.1. When we release
> sockets-1.2.1, do we also tag the parent directory and
> project-common.xml? But, changing project-common.xml makes *all*
> components go to 1.2.1.
>
> Same for Fortress....everything is 1.2, so if you fix Fortress-platform,
> you need to release all Fortress JARs. Same with instrumentation, there
> are others too.
>
> I propose doing away with project-common.xml(s), and let each project
> stands completely on it's own. In any case, most project-common.xml(s)
> have very little content anyway, there's not much we'll be duplicating.
There's three ways to do version management, the right way, the wrong way,
and the army way. Or something like that :-D
Versioning is a *hard* problem to get right. Being consistent at getting it
right is even harder, and as soon as you start being inconsistent meaning of
version numbers beyond "bigger as the previous one" quickly starts going
away.
What version of excalibur-datasource is compatible with what version of
excalibur-instrument? Can I use fortress-container-api v1.1.4 with
fortress-container-impl v1.2.1?
Historically we've never managed to get it quite right, despite trying
really really hard a few times. Reducing the number of versions and just
synchronizing them (like GNOME and affiliated projects do for example) might
seem silly, but it is a lot easier to get right.
Releasing all fortress jars with a new version number, knowing those
released jars are mutually compatible, is a lot easier than figuring out
that you need api version 1.1.4 with implementation 1.2.1, but 1.1.3 with
implemention 1.2.0. Especially three years from now. You've just witnessed
the horror it currently is to answer questions like that ;-)
When porting excalibur to svn, we made the decision to reduce the number of
versions we keep track of. I tried to identify a few "groups" that might
make sense to version seperately so it wasn't a really big shock at first.
I strongly recommend keeping it that way (even if just to keep sane), or if
changing it, changing it in the *other* direction (less seperately tracked
versions, not more). It's the only way cocoon (which has way more separate
components in there than we do) can make sure their release management
requires only partial insanity.
Having a project-common.xml is a simple and common way to keep common
metadata common, but any alternatives are all fine with me, as long as it
works.
If you're interested in the versioning problem in general, you might want to
look at stuff like .Net, maven2 and the repository stuff the DPML guys are
doing. You'll find it takes several iterations of months of hard work to get
it "right".
What a rant. Sorry!
Summary:
I advise to keep the number of versions to track and the number of
independent components to release down to a sensible level. Don't try to
"get it right", but aim for "some sort of useful, understandable and
consistent versioning".
My 2 cents from the peanut gallery,
Cheers,
Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Excalibur Release Plan
Posted by "Sasvata (Shash) Chatterjee" <sh...@badfw.org>.
>
>You should have karma now. If you don't email me.
>
>
>
Thanks a bunch, will try out tonight.
>> Given the number of modules, it'd be nice if I/we didn't have to go change
>>all the plugin.xml-s for the currentVersion and then everything else to
>>depend on the changed version numbes for every RC and then the release
>>cycle. Any ideas? One thought was to change the hard-coded version numbers
>>to Maven properties, and then define all the versions in build.properties in
>>excalibur-trunk (i.e have one file to control everything). The problem is I
>>don't know how the POM will look when deployed to a remote Maven repo.
>>
>>
>
>We had a similar setup over in Avalon which Niclas and Steve worked
>on. It would be a lot easier to have all the version numbers in one
>place.
>
>
>
I think so too. Do you happen to know if the POMs on the remote
repository retained the property notation, or actually had the expanded
value? We have written a tool for Keel, and I just read the Maven-2
will automatically do this also, to do transitive dependency checks
(i.e. look at first-level dependencies in project.xml, then retrieve
POMs for those, look at those dependencies and so on and so forth)....it
won't work if the POMs don't have the version-numbers.
>>I am assuming I do. Unless someone tells me
>>how to do this easily for all the modules, I think I am going to write
>>something in Jelly for Maven to allow use of the multiproject plugin, derive
>>a tag from currentVersion and apply the tag (doesn't look like Maven's scm,
>>repository, release plugins do what we need).
>>
>>
>
>You could tag the whole 'trunk' but tagging individual component
>directories would be much better.
>
>
>
I haven't tagged in svn yet, I'll setup a sandbox to try it out.
However, I started reading up on it yesterday, and the first thing I
learnt was that tagging isn't quite like in CVS (or, like Clearcase
"label"s); instead the "trunk" needs to be copied to a "branch" or "tag"
directory as appropriate. I saw recommendations that each project have
it's own trunk, and branch/tag dirs). It is really sub-project in our
case, considering Excalibur is the project and our "trunk" is at
Excalibur level. I am wondering if our svn structure is really suited
to the sub-project level releases, and tagging, we want to do? Somebody
help me out here....this is not a rhetorical question :-).
We could tag the entire repo for each sub-project release and tag, but
that seems sheer overkill to me. Since we haven't tagged yet, this
might be a good time to rearrange the repo as we need, once and for all.
>> BTW, project-common.xml is
>>evil for this purpose....need to tag the parent dir even though only a
>>nested dir/project is being released.
>>
>>
>
>You want to include the 'buildsystem' directory in each tag? One
>layout I suppose would be:
>
> /tags
> /${artifact}-${version}
> /buildsystem
> /[actual source directories here]
>
>Is this what you were envisioning?
>
>
>
I hadn't thought about buildsystem actually. Take cornerstone for
example. there is a trunk/cornerstone/project-common.xml, that defines
the currentVersion as "1.2". In this case all the cornerstone
components are actuall being released as 1.2, so no problem. Let's say
we make a bug fix to sockets-impl...making it 1.2.1. When we release
sockets-1.2.1, do we also tag the parent directory and
project-common.xml? But, changing project-common.xml makes *all*
components go to 1.2.1.
Same for Fortress....everything is 1.2, so if you fix Fortress-platform,
you need to release all Fortress JARs. Same with instrumentation, there
are others too.
I propose doing away with project-common.xml(s), and let each project
stands completely on it's own. In any case, most project-common.xml(s)
have very little content anyway, there's not much we'll be duplicating.
Shash
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Excalibur Release Plan
Posted by "Sasvata (Shash) Chatterjee" <sh...@badfw.org>.
Leo,
>Uh, please do tag the entire trunk for a specific version of a specific
>component, ie something like
>
>$ svn cp https://svn.apache.org/repos/asf/excalibur/trunk \
> https://svn.apache.org/repos/asf/excalibur/tags/excalibur-blah.x.y
>
>Copies in SVN are real cheap, and doing things this way makes it a lot
>easier to track version (mis)matches years down the road, etc etc.
>
>
>
No matter how cheap, copying the entire tree has got to be more than
just tagging the parts we need. Since we have (tagged) POMs that will
tell us the dependency versions, we can figure out the state of the
other modules when a particular module is released and tagged. However,
that's all theory. Given that our repo is currently based on one trunk
for all of Excalibur, I am fine with copying/tagging the entire trunk
for the release of each component/module.
>Also note the stuff in buildsystem/ already does this kind of tagging, might
>want to look at that.
>
>
>
Will do....thanks for the pointer.
>Why is it evil to tag the entire tree? It doesn't cost us any disk space,
>you can be certain that everything in /tags is a copy of something that was
>a /trunk at one point, you get an easy way to figure out what state the tree
>was in when a release was made, etc etc.
>
>
>
Really shouldn't care about the rest of the tree as long as we are
releasing/tagging each module on it's own. The "other" Avalon components
in the tree should appear to the component in question just the same as
any old dependency from some other project (which of course will not be
tagged).
But, that's for the sake of arguments; as above, going with the entire
trunk copy for now.
>SVN is simply way better for this kind of stuff than CVS :-D
>
>
>
I do like the fact that we can move files/dirs ariund without loosing
history.
>In general
>==========
>Thanks for getting to work on this! Please make sure to follow through on or
>update
>http://wiki.apache.org/excalibur/ReleaseManagement and
>http://wiki.apache.org/avalon/AvalonReleaseManagerHowto (hmm, might make
>sense to copy the information in there that's still useful over to our own
>wiki).
>
>It's not *that* big of a problem if a release isn't perfect as long as its
>real easy to retract it and publish an updated version. "Real easy" among
>other things means being very thorough in documenting all the steps and
>automating as much as possible.
>
>Finally, let's please make sure to not mess up http://www.apache.org/dist/.
>It took quite a bit of effort to get that cleaned up (Henk Pennig maintains
>stats on that@ http://people.apache.org/~henkp/) :-D
>
>
Will do. Aaron and infrastructure are still trying to get me access so
I can commit (my testcase is the typo you mentioned, so don't fix it
:-)). I will update, reuse, automate, document :-)
Shash
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Excalibur Release Plan
Posted by Leo Simons <ma...@leosimons.com>.
SVN
===
On 11-04-2005 16:56, "J Aaron Farr" <ja...@gmail.com> wrote:
>> Do I need to tag SVN for this?
>
> Yes.
>
>> I am assuming I do. Unless someone tells me
>> how to do this easily for all the modules, I think I am going to write
>> something in Jelly for Maven to allow use of the multiproject plugin, derive
>> a tag from currentVersion and apply the tag (doesn't look like Maven's scm,
>> repository, release plugins do what we need).
>
> You could tag the whole 'trunk' but tagging individual component
> directories would be much better.
Uh, please do tag the entire trunk for a specific version of a specific
component, ie something like
$ svn cp https://svn.apache.org/repos/asf/excalibur/trunk \
https://svn.apache.org/repos/asf/excalibur/tags/excalibur-blah.x.y
Copies in SVN are real cheap, and doing things this way makes it a lot
easier to track version (mis)matches years down the road, etc etc.
Also note the stuff in buildsystem/ already does this kind of tagging, might
want to look at that.
>> BTW, project-common.xml is
>> evil for this purpose....need to tag the parent dir even though only a
>> nested dir/project is being released.
>
> You want to include the 'buildsystem' directory in each tag? One
> layout I suppose would be:
>
> /tags
> /${artifact}-${version}
> /buildsystem
> /[actual source directories here]
>
> Is this what you were envisioning?
Why is it evil to tag the entire tree? It doesn't cost us any disk space,
you can be certain that everything in /tags is a copy of something that was
a /trunk at one point, you get an easy way to figure out what state the tree
was in when a release was made, etc etc.
SVN is simply way better for this kind of stuff than CVS :-D
In general
==========
Thanks for getting to work on this! Please make sure to follow through on or
update
http://wiki.apache.org/excalibur/ReleaseManagement and
http://wiki.apache.org/avalon/AvalonReleaseManagerHowto (hmm, might make
sense to copy the information in there that's still useful over to our own
wiki).
It's not *that* big of a problem if a release isn't perfect as long as its
real easy to retract it and publish an updated version. "Real easy" among
other things means being very thorough in documenting all the steps and
automating as much as possible.
Finally, let's please make sure to not mess up http://www.apache.org/dist/.
It took quite a bit of effort to get that cleaned up (Henk Pennig maintains
stats on that@ http://people.apache.org/~henkp/) :-D
Cheers!
Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Excalibur Release Plan (was: Re: Release excalibur-logger, -pool, -component.)
Posted by J Aaron Farr <ja...@gmail.com>.
On Apr 10, 2005 3:04 PM, Shash Chatterjee <sh...@badfw.org> wrote:
> 1. Someone steps up as "Release Manager" to spearhead the release
>
> yours truly
Thanks!
> I have gone through and updated all the POMs. Everything builds and
> whatever tests are there run fine. As it turned out, latest FW is 4.3 (not
> 4.2.0). At the moment I cannot check anything in, evidently I lack
> "karma".
You should have karma now. If you don't email me.
> Given the number of modules, it'd be nice if I/we didn't have to go change
> all the plugin.xml-s for the currentVersion and then everything else to
> depend on the changed version numbes for every RC and then the release
> cycle. Any ideas? One thought was to change the hard-coded version numbers
> to Maven properties, and then define all the versions in build.properties in
> excalibur-trunk (i.e have one file to control everything). The problem is I
> don't know how the POM will look when deployed to a remote Maven repo.
We had a similar setup over in Avalon which Niclas and Steve worked
on. It would be a lot easier to have all the version numbers in one
place.
> Do I need to tag SVN for this?
Yes.
> I am assuming I do. Unless someone tells me
> how to do this easily for all the modules, I think I am going to write
> something in Jelly for Maven to allow use of the multiproject plugin, derive
> a tag from currentVersion and apply the tag (doesn't look like Maven's scm,
> repository, release plugins do what we need).
You could tag the whole 'trunk' but tagging individual component
directories would be much better.
> BTW, project-common.xml is
> evil for this purpose....need to tag the parent dir even though only a
> nested dir/project is being released.
You want to include the 'buildsystem' directory in each tag? One
layout I suppose would be:
/tags
/${artifact}-${version}
/buildsystem
/[actual source directories here]
Is this what you were envisioning?
> Do we need to do source releases for the RC-s?
Preferably.
--
jaaron
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Excalibur Release Plan (was: Re: Release excalibur-logger, -pool,
-component.)
Posted by Shash Chatterjee <sh...@badfw.org>.
>We should provide at least one release candidate distribution as
>source and binary before any final release. General workflow for a
>release looks like:
>
> 1. Someone steps up as "Release Manager" to spearhead the release
>
>
yours truly
> 2. Cleans up the code and identifies a revision number for an RC release
>
>
I have gone through and updated all the POMs. Everything builds and
whatever tests are there run fine. As it turned out, latest FW is 4.3
(not 4.2.0). *At the moment I cannot check anything in, evidently I
lack "karma"*.
Here's the list of the new (to be released) versions (I am proposing
releasing some deprecated ones as well, just to get everything up to FW
4.3 and to tag the release):
avalon-framework-api - 4.3
avalon-framework-impl - 4.3
avalon-logkit - 2.1
excalibur-component - 1.3
excalibur-component-examples - 1.0
excalibur-component-tests - 1.3
excalibur-datasource - 1.3
excalibur-event-{api,impl} - 2.1
excalibur-fortress-{bean,cli,container-api,container-impl,container-test,examples,meta,migration,platform,servlet,testcase}
- 1.2
excalibur-instrument-{api,client,mgr-api,mgr-http,mgr-impl) - 1.2
excalibur-lifecycle-{api,impl} - 1.2
excalibur-logger - 1.2
excalibur-monitor - 1.2
excalibur-pool-{api,impl,instrumented} - 2.1
excalibur-sourceresolve - 2.1
excalibur-store - 1.2
excalibur-testcase - 3.1
excalibur-thread-{api,impl,instrumented} - 2.1
excalibur-xmlutil - 1.2
cornerstone-connection-{api,impl} - 2.1
cornerstone-datasources-{api,impl} - 2.1
cornerstone-scheduler-{api,impl} - 2.1
cornerstone-sockets-{api,impl} - 2.1
cornerstone-store-{api,impl} - 2.1
cornerstone-threads-{api,impl,tutorial} - 2.1
maven-fortress-plugin - 0.2
I have changed all the 3rd-party dependencies as follows:
ant - 1.6.2
bcel - 5.1
commons-beanutils - 1.7.0
commons-collections - 3.1
commons-httpclient - 2.0.2
commons-logging - 1.0.4
commons-vfs - 20050307052300
concurrent - 1.3.4
jisp - 2.5.1
junit - 3.8.1
juintperf - 1.8.1
hsqldb - 1.7.1 (1.7.3 causes test failure...need to chase)
log4j - 1.2.8
qdox - 1.5
servletapi - 2.3
xalan - 2.6.0
xerces - 2.4.0
xml-apis - 2.0.2
> 3. PMC signs off on a RC release
>
>
I guess this can happen after I checkin my changes and everybody gets a
chance to try from SVN.
Given the number of modules, it'd be nice if I/we didn't have to go
change all the plugin.xml-s for the currentVersion and then everything
else to depend on the changed version numbes for every RC and then the
release cycle. Any ideas? One thought was to change the hard-coded
version numbers to Maven properties, and then define all the versions in
build.properties in excalibur-trunk (i.e have one file to control
everything). The problem is I don't know how the POM will look when
deployed to a remote Maven repo.
> 4. Release Manager publishes the RC release
>
>
Do I need to tag SVN for this? I am assuming I do. Unless someone tells
me how to do this easily for all the modules, I think I am going to
write something in Jelly for Maven to allow use of the multiproject
plugin, derive a tag from currentVersion and apply the tag (doesn't look
like Maven's scm, repository, release plugins do what we need). BTW,
project-common.xml is evil for this purpose....need to tag the parent
dir even though only a nested dir/project is being released.
Do we need to do source releases for the RC-s?
Shash
Re: Release excalibur-logger, -pool, -component...
Posted by J Aaron Farr <ja...@gmail.com>.
On 5/31/05, Shash Chatterjee <sh...@badfw.org> wrote:
> Sorry, but I have been swamped both at work and at home.
I know the feeling.
> I am traveling
> outside the US starting Saturday, for 3 weeks. I will attempt to get
> started on the repo tagging as and when I get time in the evenings in our
> office apartment in Shanghai. Don't know if the cheap 啤酒 (pi jiu, beer)
> will affect my work!
Let me know if there is anything I can do to help.
--
jaaron
Re: Release excalibur-logger, -pool, -component...
Posted by Shash Chatterjee <sh...@badfw.org>.
>
> Guys, any news / progress on releasing the stuff?
>
Sorry, but I have been swamped both at work and at home. I am traveling
outside the US starting Saturday, for 3 weeks. I will attempt to get
started on the repo tagging as and when I get time in the evenings in
our office apartment in Shanghai. Don't know if the cheap ?? (pi jiu,
beer) will affect my work!
Shash
Re: Release excalibur-logger, -pool, -component...
Posted by Vadim Gritsenko <va...@reverycodes.com>.
J Aaron Farr wrote:
> On Apr 7, 2005 2:22 PM, Sasvata (Shash) Chatterjee <sh...@badfw.org> wrote:
>
>>Aaron, let us know what you are thinking (as you sit in that chair, no
>>wait, you *are* the chair :-)). Framework, Logkit first, then, per
>>Vadim's immediate needs, looger, pool, component, then everything else?
>
> I would go with Framework + Logkit followed by the rest of the
> "containerkit" subprojects and then by Fortress and the components.
Guys, any news / progress on releasing the stuff?
Thanks,
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Release excalibur-logger, -pool, -component...
Posted by J Aaron Farr <ja...@gmail.com>.
On Apr 7, 2005 2:22 PM, Sasvata (Shash) Chatterjee <sh...@badfw.org> wrote:
> Aaron, let us know what you are thinking (as you sit in that chair, no
> wait, you *are* the chair :-)). Framework, Logkit first, then, per
> Vadim's immediate needs, looger, pool, component, then everything else?
I would go with Framework + Logkit followed by the rest of the
"containerkit" subprojects and then by Fortress and the components.
> Also, once everything builds/tests, do we want to release some SNAPSHOT
> jars, or do we want folks to just build from source and try out prior to
> the actual release?
We should provide at least one release candidate distribution as
source and binary before any final release. General workflow for a
release looks like:
1. Someone steps up as "Release Manager" to spearhead the release
2. Cleans up the code and identifies a revision number for an RC release
3. PMC signs off on a RC release
4. Release Manager publishes the RC release
5. Start collecting bugs (if any) via JIRA
6. If there are bugs, do another RC release.
7. When the RC has been stable for at least a week (no new bug
reports), request a formal release by the PMC
see also: http://wiki.apache.org/avalon/AvalonReleaseManagerHowto
The Avalon framework is a widely used dependency, so a new release
candidate is something many other projects may want to know about.
--
jaaron
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Release excalibur-logger, -pool, -component...
Posted by "Sasvata (Shash) Chatterjee" <sh...@badfw.org>.
>
> Actually, the changes are fairly minimal. Attached is the cleaned up
> diff (I removed license switch, changes in test/ directory, and some
> cosmetic changes) - it's failry small.
>
> So, I do not have any objections to base all releases on the framework
> 4.2 release.
>
Thanks for digging. I'll try to get everything converted to 4.2 this
weekend (that's the earliest I can get to it), and report back here,
most likely everything will work.
Aaron, let us know what you are thinking (as you sit in that chair, no
wait, you *are* the chair :-)). Framework, Logkit first, then, per
Vadim's immediate needs, looger, pool, component, then everything else?
Also, once everything builds/tests, do we want to release some SNAPSHOT
jars, or do we want folks to just build from source and try out prior to
the actual release?
Shash
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Release excalibur-logger, -pool, -component...
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sasvata (Shash) Chatterjee wrote:
>
>> Is there any backward incompatibility problems with 4.2, as related to
>> 4.1.5?
>>
>> If 4.2 is compatible with 4.1.5, I have no issues with that plan. If
>> not, I'd suggest either to release bunch of components compiled
>> against older stable version, and/or ensure that 4.2 is compatible
>> with 4.1.5.
>
>
> I don't know.
Actually, the changes are fairly minimal. Attached is the cleaned up diff (I
removed license switch, changes in test/ directory, and some cosmetic changes) -
it's failry small.
So, I do not have any objections to base all releases on the framework 4.2 release.
Vadim
> On Keel, we too are on 4.1.5. I can try rolling all the
> components back to 4.1.5 and see if all the tests run (assuming
> everything compiles), and I agree that would be a good baseline to
> start. In theory, the second field changing means 4.2.x should be
> backward-compatible with 4.1.x, I don't know what will happen in
> practice. We can then turn around and baseline on 4.2 right after that,
> so we can see the changes between 4.1.5. Of course, somebody might pipe
> up and tell us before that :-)
>
> Shash
Re: Release excalibur-logger, -pool, -component...
Posted by "Sasvata (Shash) Chatterjee" <sh...@badfw.org>.
>
>> I like Leo's suggestion a few days back to sync everything to the
>> latest framework, it would allow us to re-establish a baseline on the
>> SVN repo. If nobody has a general objection to this, I can (locally)
>> start changing all the projects to depend on framework 4.2-dev and
>> the latest logkit, and see how the tests fare?
>
>
> Is there any backward incompatibility problems with 4.2, as related to
> 4.1.5?
>
> If 4.2 is compatible with 4.1.5, I have no issues with that plan. If
> not, I'd suggest either to release bunch of components compiled
> against older stable version, and/or ensure that 4.2 is compatible
> with 4.1.5.
I don't know. On Keel, we too are on 4.1.5. I can try rolling all the
components back to 4.1.5 and see if all the tests run (assuming
everything compiles), and I agree that would be a good baseline to
start. In theory, the second field changing means 4.2.x should be
backward-compatible with 4.1.x, I don't know what will happen in
practice. We can then turn around and baseline on 4.2 right after that,
so we can see the changes between 4.1.5. Of course, somebody might pipe
up and tell us before that :-)
Shash
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Release excalibur-logger, -pool, -component...
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sasvata (Shash) Chatterjee wrote:
> Vadim,
>
>> I'd like to get some excalibur components released. There are couple
>> of reasons for that, one is bugfixes applied to trunk, and another is
>> that releases which are out there compiled with jdk 1.4 (instead of
>> 1.3), and due to the fact that I do not see any tags in SVN (neither
>> do know what revision number was used to build component releases), I
>> think it's easier to make a bugfix release with a tag then to make
>> attempts to find proper revision to do a re-builds.
>
>
> I think we need to start doing the tagging, sooner rather than later.
+1000 to that! That what I was hoping to do.
> I too have had a hard time figuring out differences in the current code
> compared to the released versions (I have some idea by looking at the
> obsolete *CVS* repository, which is still out there, but of course I
> can't compare to the very lagtest code).
>
> But, which components? And what framework-dependency?
Umm, I'm not up to speed on latest framework versions. We (Cocoon) are on
avalon-framework 4.1.5.
> I like Leo's suggestion a few days back to sync everything to the latest
> framework, it would allow us to re-establish a baseline on the SVN
> repo. If nobody has a general objection to this, I can (locally) start
> changing all the projects to depend on framework 4.2-dev and the latest
> logkit, and see how the tests fare?
Is there any backward incompatibility problems with 4.2, as related to 4.1.5?
If 4.2 is compatible with 4.1.5, I have no issues with that plan. If not, I'd
suggest either to release bunch of components compiled against older stable
version, and/or ensure that 4.2 is compatible with 4.1.5.
Thanks,
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Release excalibur-logger, -pool, -component...
Posted by "Sasvata (Shash) Chatterjee" <sh...@badfw.org>.
Vadim,
>
> I'd like to get some excalibur components released. There are couple
> of reasons for that, one is bugfixes applied to trunk, and another is
> that releases which are out there compiled with jdk 1.4 (instead of
> 1.3), and due to the fact that I do not see any tags in SVN (neither
> do know what revision number was used to build component releases), I
> think it's easier to make a bugfix release with a tag then to make
> attempts to find proper revision to do a re-builds.
I think we need to start doing the tagging, sooner rather than later. I
too have had a hard time figuring out differences in the current code
compared to the released versions (I have some idea by looking at the
obsolete *CVS* repository, which is still out there, but of course I
can't compare to the very lagtest code).
But, which components? And what framework-dependency?
I like Leo's suggestion a few days back to sync everything to the latest
framework, it would allow us to re-establish a baseline on the SVN
repo. If nobody has a general objection to this, I can (locally) start
changing all the projects to depend on framework 4.2-dev and the latest
logkit, and see how the tests fare?
Shash
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org