You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Sutic <le...@inspireinfrastructure.com> on 2004/02/20 21:08:07 UTC
Versioning scheme
All,
since I'll be doing some releasing, I started thinking
about what goes into a version number. The Apache
Portable Runtime says this:
(http://apr.apache.org/versioning.html)
= The Basics =
Versions are denoted using a standard triplet of
integers: MAJOR.MINOR.PATCH. The basic intent is that
MAJOR versions are incompatible, large-scale upgrades
of the API. MINOR versions retain source and binary
compatibility with older minor versions, and changes
in the PATCH level are perfectly compatible, forwards
and backwards.
It is important to note that a library that has not
reached 1.0.0 is not subject to the guidelines
described in this document. Before a 1.0 release
(version 0.x.y), the API can and will be changing
freely, without regard to the restrictions detailed
below.
== Source Compatibility ==
We define "source compatible" to mean that an
application will continue to build without error,
and that the semantics will remain unchanged.
Applications that write against a particular version
will remain source-compatible against later versions,
until the major number changes. However, if an
application uses an API which has become available
in a particular minor version, it (obviously) will
no longer build or operate against previous minor
versions.
== Binary Compatibility ==
We define "binary compatible" to mean that a compiled
application can be linked (possibly dynamically)
against the library and continue to function properly.
Similar to source compatibility, an application that
has been compiled against a particular version will
continue to be linkable against later versions (unless
the major number changes). It is possible that an
application will not be able to successfully link
against a previous minor version.
= Examples =
Here are some examples to demonstrate the compatibility:
|| Original Version |||| New Version |||| Compatible? ||
|| 2.2.3 |||| 2.2.4 |||| Yes Compatibility across patch
versions is guaranteed. ||
|| 2.2.3 |||| 2.2.1 Yes |||| Compatibility across patch
versions is guaranteed. ||
|| 2.2.3 |||| 2.3.1 Yes |||| Compatibility with later minor
versions is guaranteed. ||
|| 2.2.3 |||| 2.1.7 No |||| Compatibility with prior minor
versions is not guaranteed. ||
|| 2.2.3 |||| 3.0.0 No |||| Compatibility with different
major versions is not guaranteed. ||
|| 2.2.3 |||| 1.4.7 No |||| Compatibility with different
major versions is not guaranteed. ||
Note: while some of the cells say "no", it is
possible that the versions may be compatible,
depending very precisely upon the particular
APIs used by the application.
----------------------------------
Should we adopt this?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Versioning scheme
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
> Should we adopt this?
+1
Steve.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL]: Version consistency using enities (was: Versioning scheme)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 22 February 2004 20:55, Jörg Schaible wrote:
> Niclas Hedhman wrote:
> > On Sunday 22 February 2004 06:26, Jörg Schaible wrote:
> >> Well, you can introduce entities in your project XML files for
> >> dependencies and versions. In the end you will not have one file with
> >> all versions, but a directory will all entities containing the version
> >> or dependency.
> >
> > Works great if all versioning information sits in XML files... which
> > unfortunately is not true :o/
>
> What do you refer in special?
Maybe it is only me, but I typically have a large array of content that is
updated over the course of a product life cycle, version of your own and
other products being one.
The fact that I do build a generic build system, that handles "my type" of
projects, even done outside my own organization and team, means that stuff
like;
Company Names
Product or Project Names
Contact names and numbers.
URLs of many types.
Licensing references and inclusions.
and a bunch more I can recall just off-hand...
And having a list of 2 dozen "Macros" that you insert whereever you need,
without having to worry how that is resolved is just great.
(I even have a build system that builds build systems for customers, in this
fashion.)
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL]: Version consistency using enities (was: Versioning scheme)
Posted by Jörg Schaible <jo...@gmx.de>.
Niclas Hedhman wrote:
> On Sunday 22 February 2004 06:26, Jörg Schaible wrote:
>> Well, you can introduce entities in your project XML files for
>> dependencies and versions. In the end you will not have one file with all
>> versions, but a directory will all entities containing the version or
>> dependency.
>
> Works great if all versioning information sits in XML files... which
> unfortunately is not true :o/
What do you refer in special?
Regards,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [PROPOSAL]: Version consistency using enities (was: Versioning scheme)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 22 February 2004 06:26, Jörg Schaible wrote:
> Well, you can introduce entities in your project XML files for dependencies
> and versions. In the end you will not have one file with all versions, but
> a directory will all entities containing the version or dependency.
Works great if all versioning information sits in XML files... which
unfortunately is not true :o/
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
[PROPOSAL]: Version consistency using enities (was: Versioning scheme)
Posted by Jörg Schaible <jo...@gmx.de>.
Niclas Hedhman wrote:
> On Saturday 21 February 2004 17:21, Leo Simons wrote:
>> Leo Sutic wrote:
>> > Should we adopt this?
>>
>> sounds like a plan. It will be difficult to stick to. Avalon is rather
>> unique in releasing lots of small bits seperately :D
>
> Currently we have some 'inefficiencies" in the versioning of all the
> products. For instance, it is almost impossible to know all the places
> where changes are required when you need to bump the versions.
> I used to employ the "copy all source to build directory with a 'replace'
> filter", which I think I learned from Cocoon, and then have one file for
> the versioning information.
>
> Once that is in place, it would be fairly easy to automate the whole
> release process as well.
Well, you can introduce entities in your project XML files for dependencies
and versions. In the end you will not have one file with all versions, but
a directory will all entities containing the version or dependency. I am
using this in a project and it works wonderful.
Example for a modified framework/api/project.xml
===================================
<!DOCTYPE project [
<!ENTITY dep-logkit SYSTEM "../../buildsystem/dependency/logkit.entity">
]>
[...]
<dependencies>
&dep-logkit;
</dependencies>
[...]
Example for a modified framework/impl/project.xml
===================================
<!DOCTYPE project [
<!ENTITY dep-avalon-framework-api SYSTEM
"../../buildsystem/dependency/avalon-framework-api.entity">
<!ENTITY dep-xml-apis SYSTEM
"../../buildsystem/dependency/xml-apis.entity">
<!ENTITY dep-xerces SYSTEM "../../buildsystem/dependency/xerces.entity">
<!ENTITY dep-xalan SYSTEM "../../buildsystem/dependency/xalan.entity">
<!ENTITY dep-logkit SYSTEM "../../buildsystem/dependency/logkit.entity">
<!ENTITY dep-junit SYSTEM "../../buildsystem/dependency/junit.entity">
]>
[...]
<dependencies>
&dep-avalon-framework-api;
&dep-xml-apis;
&dep-xerces;
&dep-xalan;
&dep-logkit;
&dep-junit;
</dependencies>
[...]
Working with entities has one drawback: They are always relative to the file
they're included. So if you include a project.xml from another directory
level, the entities are not found.
Fortunately dependencies are in Avalon currently declared only in
project.xml's two levels deep, so this proposal will work! Additionally it
will ensure that never two Avalon assemblies will reference the same
assembly as dependency in two different versions.
Regards,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Versioning scheme
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 21 February 2004 18:55, Leo Simons wrote:
> [1] -- http://www.jroller.com/comments/lsd?anchor=moving_away_from_maven
<quote>
I don't care so much about what xml format to use, what file structure
organisation to use, how plugins work. I don't really care that maven is slow
and inefficient, or that it leaks huge amount of memory for some tasks. I
don't mind it uses an ugly xml scripting language.
</quote>
I do care about these as well...
And how about, "No support in other products, such as IDEs." and "Releases
every 6 months or so"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: ant instead of maven
Posted by Leo Simons <le...@apache.org>.
Carsten Ziegeler wrote:
> Leo Simons wrote:
>
>>Carsten Ziegeler wrote:
>>
>>>stick to the "rules"
>>
>>that is something we likely do not want to do :D
>
> Yes, why taking the easy and fast road, if you have the choice of
> using the uncomfortable, slow and painful one? :-)
what seemed easy and fast a few months ago has turned out to be
uncomfortable, slow and painful!
What seemed difficult, slow and a maintainance nightmare is turning out
to be quite fast and comfortable, though...
http://www.jroller.com/comments/lsd?anchor=big_build_systems_using_ant
gnight!
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: ant instead of maven
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Leo Simons wrote:
>
> Carsten Ziegeler wrote:
> > stick to the "rules"
>
> that is something we likely do not want to do :D
>
Yes, why taking the easy and fast road, if you have the choice of
using the uncomfortable, slow and painful one? :-)
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: ant instead of maven
Posted by Leo Simons <le...@apache.org>.
Carsten Ziegeler wrote:
> stick to the "rules"
that is something we likely do not want to do :D
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: ant instead of maven
Posted by Stephen McConnell <mc...@apache.org>.
J Aaron Farr wrote:
> True. I've been using Maven since something like beta-7 I think. Right
> now I still use beta-10 since I got inconsistent results with RC-1.
> Each time I upgraded to a new beta, it required reworking things.
Things changing with a new beta don't bother me. I can prepare myself
for that. But what *really* bugs me is when things change because maven
it changing under your feet.
Some things I've been experiencing (which have nothing to do with jelly)
is maven downloading of *older* jar files over more recent build
versions. This came up because of a build failure related to a class
not found error. The class in question has just been built and installed
into the repository by maven - then on the build of a subsequent project
maven downloaded an older version (as in days older). Problem is that
the bug is non-repeatable (but I now know of at least three cases where
this was the identified cause of a build failure). I have a hunch that
the issue is related to the difference in precision in date formats
returned from input streams where the resource is local or remote (http
resources return a different date precision to file resources) - but I
haven't gone digging.
Anyway - the problems have been sufficient to prompt me to thinking
about putting in place a component that runs a sequence of actionable
services - e.g. compile, test, jar, etc. The key here is defining these
actions as services - not implementations. This would enable a lot
cleaner build model because plugins would be basically full components.
But that idea hasn't gone beyond a few little test components (but its
still circulating in my head).
Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: ant instead of maven (was: Re: Versioning scheme)
Posted by J Aaron Farr <fa...@apache.org>.
On Sat, 2004-02-21 at 10:54, Stephen McConnell wrote:
> Its not that. The real issue is that maven is moving underneath your
> feet. Do a build today - go away for a holiday - come back - redo the
> build and guess what - don't be too surprised it the result is
> different. BTW the only download is the maven plugin.
>
> Apparently RC2 is a couple of weeks away. I'm going to give that a shot
> but if I seem the same sort of inconsistencies - well, I'm going to
> spending a lot more time looking into ant documentation.
>
> Stephen.
True. I've been using Maven since something like beta-7 I think. Right
now I still use beta-10 since I got inconsistent results with RC-1.
Each time I upgraded to a new beta, it required reworking things.
I agree with Leo's point (on his blog) "let it mature." Of course as
soon as Maven reaches 1.0, everyone's going to want to look at Maven 2.
--
jaaron <http://jadetower.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: ant instead of maven (was: Re: Versioning scheme)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stephen McConnell wrote:
>
> Its not that. The real issue is that maven is moving
> underneath your feet. Do a build today - go away for a
> holiday - come back - redo the build and guess what - don't
> be too surprised it the result is different. BTW the only
> download is the maven plugin.
>
> Apparently RC2 is a couple of weeks away. I'm going to give
> that a shot but if I seem the same sort of inconsistencies -
> well, I'm going to spending a lot more time looking into ant
> documentation.
>
We are using Maven for months without any problems. But you really
should stick to the "rules" Maven implies. If you start building
your own build system on top, then you're obviously doing something
wrong and should better use Ant.
Now, I don't see any need for a different build system than Maven
here at Avalon. If the current system would be stripped down
and simple use all available things from Maven without extending
here and there, then I bet it will build everything Avalon needs
without any problems.
We all know how painfull the old Ant system was and how long it
took until it worked and we all know how long the move to Maven
took. So switching back to Ant is imho the wrong way. Simplify
the current build system and throw away all Avalon specific goals.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: ant instead of maven (was: Re: Versioning scheme)
Posted by Stephen McConnell <mc...@apache.org>.
J Aaron Farr wrote:
> On Sat, 2004-02-21 at 09:08, Carsten Ziegeler wrote:
>
>>I think Maven is quiet good and one major problem we have is that we not
>>using Maven the right way. Instead of using the provided goals we have
>>many Avalon:yxz goals and a lot of magic around it.
>>
>>I think we can solve all this by just using what Maven provides (except
>>adding Meta-Info).
>
>
> I think this is the case as well. Maven works wonders when you use the
> standard plugins, but when you end up writing your own build system on
> top of Maven, well, you might as well be using Ant.
Its not that. The real issue is that maven is moving underneath your
feet. Do a build today - go away for a holiday - come back - redo the
build and guess what - don't be too surprised it the result is
different. BTW the only download is the maven plugin.
Apparently RC2 is a couple of weeks away. I'm going to give that a shot
but if I seem the same sort of inconsistencies - well, I'm going to
spending a lot more time looking into ant documentation.
Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: ant instead of maven (was: Re: Versioning scheme)
Posted by J Aaron Farr <fa...@apache.org>.
On Sat, 2004-02-21 at 09:08, Carsten Ziegeler wrote:
> I think Maven is quiet good and one major problem we have is that we not
> using Maven the right way. Instead of using the provided goals we have
> many Avalon:yxz goals and a lot of magic around it.
>
> I think we can solve all this by just using what Maven provides (except
> adding Meta-Info).
I think this is the case as well. Maven works wonders when you use the
standard plugins, but when you end up writing your own build system on
top of Maven, well, you might as well be using Ant.
--
jaaron <http://jadetower.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: ant instead of maven (was: Re: Versioning scheme)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
I think Maven is quiet good and one major problem we have is that we not
using Maven the right way. Instead of using the provided goals we have
many Avalon:yxz goals and a lot of magic around it.
I think we can solve all this by just using what Maven provides (except
adding Meta-Info).
Carsten
> -----Original Message-----
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
> Sent: Saturday, February 21, 2004 2:21 PM
> To: Avalon Developers List
> Subject: Re: ant instead of maven (was: Re: Versioning scheme)
>
> On Saturday 21 February 2004 20:43, Leo Simons wrote:
> > How would you want to build the websites, for example?
>
> Keep Maven for docs ???
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org For
> additional commands, e-mail: dev-help@avalon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: ant instead of maven (was: Re: Versioning scheme)
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 21 February 2004 20:43, Leo Simons wrote:
> How would you want to build the websites, for example?
Keep Maven for docs ???
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
ant instead of maven (was: Re: Versioning scheme)
Posted by Leo Simons <le...@apache.org>.
Niclas Hedhman wrote:
>>I agree that maven is not perfect [1], but do you have any idea of the
>>work required to revamp the entire build system *again*?
>
> YES
really?
> but I am willing to do the work :o)
that's probably a full work week or two you're volunteering here ;)
How would you want to build the websites, for example?
Fork the maven reports plugins, convert them into ant scripts, maintain
the forked functionality here?
Write an XSLT-based script that transforms all documentation (including
the ones with subtle XML errors that velocity gracefully eats) sources?
The avalon website is looking quite good (especially the merlin part),
and I know how to maintain it and how to change things. It's way better
than anything we had back in the days of anakia, or later cocoon and
forrest.
My stance on any build system refactoring is simple: I'll be happy as
long as it improves in one or more directions and doesn't make things
worse in any other direction. The mailing list archives have lots of
thoughts about our build system requirements :D
My assertion is (was some time ago and has not changed) that maven will
reach a stable and good-working 1.0 release before any such makeover is
complete. Coupled with the inconvenience caused by large build system
refactorings and the amount of time investment needed to do it...I don't
think its a good idea.
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Versioning scheme
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 22 February 2004 09:31, Alex Karasulu wrote:
> That's going backwards - give maven some time to progress. The idea is a
> good one.
Btw, I think this is one of the official "Maven endorsed" logos to put on your
site.
http://avalon.apache.org/framework/images/logos/maven-petesucks.png
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Versioning scheme
Posted by Alex Karasulu <ao...@bellsouth.net>.
That's going backwards - give maven some time to progress. The idea is a
good one.
> -----Original Message-----
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
> Sent: Saturday, February 21, 2004 6:00 AM
> To: Avalon Developers List
> Subject: Re: Versioning scheme
>
> On Saturday 21 February 2004 18:55, Leo Simons wrote:
> > Niclas Hedhman wrote:
> > > Can't we just go back to Ant?
> >
> >
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaaaaaaaaaaaaaaaaaaaa
> a
> >aa..a....a.....a...........ah....umf!!!
> >
> > (sound of Leo falling from a really steep cliff and then hitting rock
> > bottom, hard)
>
> Did it hurt?
>
> > I agree that maven is not perfect [1], but do you have any idea of the
> > work required to revamp the entire build system *again*?
>
> YES, but I am willing to do the work :o)
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Versioning scheme
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 21 February 2004 18:55, Leo Simons wrote:
> Niclas Hedhman wrote:
> > Can't we just go back to Ant?
>
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaaaaaaaaaaaaaaaaaaaaa
>aa..a....a.....a...........ah....umf!!!
>
> (sound of Leo falling from a really steep cliff and then hitting rock
> bottom, hard)
Did it hurt?
> I agree that maven is not perfect [1], but do you have any idea of the
> work required to revamp the entire build system *again*?
YES, but I am willing to do the work :o)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Versioning scheme
Posted by Leo Simons <le...@apache.org>.
Niclas Hedhman wrote:
> Can't we just go back to Ant?
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaaaaaaaaaaaaaaaaaaaaaaa..a....a.....a...........ah....umf!!!
(sound of Leo falling from a really steep cliff and then hitting rock
bottom, hard)
I agree that maven is not perfect [1], but do you have any idea of the
work required to revamp the entire build system *again*?
--
cheers,
- Leo Simons
[1] -- http://www.jroller.com/comments/lsd?anchor=moving_away_from_maven
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Versioning scheme
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 21 February 2004 17:21, Leo Simons wrote:
> Leo Sutic wrote:
> > Should we adopt this?
>
> sounds like a plan. It will be difficult to stick to. Avalon is rather
> unique in releasing lots of small bits seperately :D
Currently we have some 'inefficiencies" in the versioning of all the products.
For instance, it is almost impossible to know all the places where changes are
required when you need to bump the versions.
I used to employ the "copy all source to build directory with a 'replace'
filter", which I think I learned from Cocoon, and then have one file for the
versioning information.
Once that is in place, it would be fairly easy to automate the whole release
process as well.
Now, Maven and I are not source nor binary compatible, so I am way out of my
territory to try to attempt doing this, but I still think it should be done.
(Can't we just go back to Ant?)
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Versioning scheme
Posted by Leo Simons <le...@apache.org>.
Leo Sutic wrote:
> Should we adopt this?
sounds like a plan. It will be difficult to stick to. Avalon is rather
unique in releasing lots of small bits seperately :D
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Versioning scheme
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> As changes progress I'll update X and Y
This should be automated ***somehow***... but how?
Figuring out binary compatibility can't be that hard,
just use reflection to compare new jar and old jar. If all
signatures are the same, we're good to go. Also check
serial version UIDs (method order etc.)...
Hm. that would handle patch versions - i.e. being able to
see if current CVS qualifies as a patch version.
Minor version could perhaps be handled similarly.
?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Versioning scheme
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
> One more question: The scheme depends on actually knowing what
> changes have been made to the code. I.e. what is the minimum
> version number (major, minor or patch) we must increase?
>
> Ideas?
>
> I know that Cocoon creates a whole new repo for each bump
> in minor version number.
>
> We could do something similar - perhaps have a
> avalon/framework-4.1 directory and a avalon/framework-4.2
> dir.
I don't think this necessary. If the CVS is tagged with a specific
version release you can maintain separate builds (for example I've got a
merlin and assorted sub-systems checkout all relative to 3.2.5 and
another checkout all relative to head).
Right after a release I'm typically bumping any package I modify to
X.Y-SNAPSHOT. As changes progress I'll update X and Y to reflect
backward compatibility (for example both activation and composition
packages have been bumped to 2.0-SNAPSHOT as changes are not backward
compatible with 1.X).
Cheers, Steve.
> /LS
>
>
>>From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Versioning scheme
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
One more question: The scheme depends on actually knowing what
changes have been made to the code. I.e. what is the minimum
version number (major, minor or patch) we must increase?
Ideas?
I know that Cocoon creates a whole new repo for each bump
in minor version number.
We could do something similar - perhaps have a
avalon/framework-4.1 directory and a avalon/framework-4.2
dir.
/LS
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org