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/25 14:54:01 UTC
[RT] Automatic Versioning
All,
the trials and tribulations associated with the release has made me
think about
version numbers a lot. I use Cocoon, and there's always a bit of
press-enter-
and-pray-to-god when trying out a new version of some dependent library.
The problem is that if you have libraries A and B, A is depndent on B
and both
are dependent on C, and they somehow end up being dependent on
*different*
versions of C, then it is not always possible to get things to run at
all.
Consider this:
A -dep on-> B, C-1.3
B -dep on-> C-1.4
The obvious solution for the case above would be to deploy C version
1.4.
However, this may not always solve the problem if C-1.4 isn't backwards
compatible with C-1.3.
There's little that can be done in such a case, so I was thinking about
ways to keep it from happening.
What one could do is to compare classes in the latest released jar,
and in the jar just built: If a class exists in old.jar but not in
new.jar, well, that's a major version number bump (not backward compat).
Comparing classes from both jars:
1. If two classes have the exact same public and protected methods,
they are both forward and backwards compatible. Increase patch
version
number.
2. If a method has been added to a class it is backwards compatible.
Increase minor version number.
3. If a method has been added to an interface:
a. If the interface isn't implemented by clients:
Increase minor version number.
b. If the interface is implemented by clients:
Increase major version number.
4. If a method has been removed from a class:
Increase major version number.
5. If a method has been removed from an interface:
a. If the interface isn't implemented by clients:
Increase major version number.
b. If the interface is implemented by clients:
Increase minor version number.
The above could be made into an Ant task.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Automatic Versioning
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 26 February 2004 00:53, Leo Sutic wrote:
> A major version bump means that *anything* may have changed.
>
> Demanding a package rename is a bit too much. Consider the
> major version number part of the package name.
IMHO, it is exactly this kind of "lax attitude" that led to the infamous
DOM1/DOM2 nigthmare. Incompatible interfaces with the same names.
I am pro-force, a.k.a "we developers are too stupid for our own good" :D
Why would allow to knowingly create future problems?
In any event, as I said I think the tool should "Report" and then the
responsible party (PMC) make the decision.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] Automatic Versioning
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
> Sent: den 25 februari 2004 16:56
> To: Avalon Developers List
> Subject: Re: [RT] Automatic Versioning
>
>
> On Wednesday 25 February 2004 21:54, Leo Sutic wrote:
> > Consider this:
> >
> > A -dep on-> B, C-1.3
> > B -dep on-> C-1.4
> >
> > The obvious solution for the case above would be to deploy
> C version
> > 1.4.
> >
> > However, this may not always solve the problem if C-1.4 isn't
> > backwards compatible with C-1.3.
>
> Yes, bad versioning in C, can lead to this.
> But if "B -dep on-> C-2.0" doesn't help anyway, since if the
> method signatures
> are not compatible, there will still be problems, bumping the
> numbers doesn't
> solve anything by itself. Agree?
Yes.
> So, in your LIST, I don't want to see "Method Removed from
> interface increase
> Major", but "Method Removed from interface -> REFUSE PUBLISH,
> and demand package renaming."
> Any non-backward compatible change, must result in "refuse
> publish", and the guidelines for what can and can not be done
> can be found in documents from Sun.
A major version bump means that *anything* may have changed.
Demanding a package rename is a bit too much. Consider the
major version number part of the package name.
I agree with the use of this tool - it is only for helping the
release manager determine what changes have been made between
the two versions.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Automatic Versioning
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 25 February 2004 21:54, Leo Sutic wrote:
> Consider this:
>
> A -dep on-> B, C-1.3
> B -dep on-> C-1.4
>
> The obvious solution for the case above would be to deploy C version
> 1.4.
>
> However, this may not always solve the problem if C-1.4 isn't backwards
> compatible with C-1.3.
Yes, bad versioning in C, can lead to this.
But if "B -dep on-> C-2.0" doesn't help anyway, since if the method signatures
are not compatible, there will still be problems, bumping the numbers doesn't
solve anything by itself. Agree?
So, in your LIST, I don't want to see "Method Removed from interface increase
Major", but "Method Removed from interface -> REFUSE PUBLISH, and demand
package renaming."
Any non-backward compatible change, must result in "refuse publish", and the
guidelines for what can and can not be done can be found in documents from
Sun.
Alsom, I am much more in favour of 'analysis of change and report' than
'figure out a new version number and apply', because if it is only a matter
of
ant release-major
ant release-minor
ant release-micro
(or equivalent in Maven)
then I think the 'release coordinator' can manage that after been given
relevant information.
Cheers,
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] Automatic Versioning
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Leo Simons
> Sent: den 25 februari 2004 21:01
> To: dev@avalon.apache.org
> Subject: Re: [RT] Automatic Versioning
>
>
> Leo Sutic wrote:
>
> > [jar hell]
> > There's little that can be done in such a case
>
> .Net pulls it off IMVHO. Aside from the default settings of visual
> studio (spit), I think they pretty much figured something
> workable out.
Any pointers to how they did it?
> > I was thinking about
> > ways to keep it from happening.
>
> I think any kind of versioning scheme will still not be able to
> "enforce" enough rigidity, lest it become too much of a pain. I think
> what is much more valuable is solid integration testing (gump!).
>
> > The above could be made into an Ant task.
>
> the algorithm is nice, and makes sense. It seems like this could be a
> valuable reporting tool. But I'm a little scared because of the
> "automatic"...just some thoughts ;)
Yes, the tool is a reporting tool. It is up to the release manager
to figure out what to do with the data.
It automates the checking, but not the actual versioning.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Automatic Versioning
Posted by Leo Simons <le...@apache.org>.
Leo Sutic wrote:
> [jar hell]
> There's little that can be done in such a case
.Net pulls it off IMVHO. Aside from the default settings of visual
studio (spit), I think they pretty much figured something workable out.
> I was thinking about
> ways to keep it from happening.
I think any kind of versioning scheme will still not be able to
"enforce" enough rigidity, lest it become too much of a pain. I think
what is much more valuable is solid integration testing (gump!).
> The above could be made into an Ant task.
the algorithm is nice, and makes sense. It seems like this could be a
valuable reporting tool. But I'm a little scared because of the
"automatic"...just some thoughts ;)
--
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: [RT] Automatic Versioning
Posted by hammett <ha...@uol.com.br>.
Very nice. I don't feel like get bounded by some released version of some
class/interface too >:-)
--
hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org