Tim Larson wrote:
On Thu, Apr 22, 2004 at 09:50:08PM +0200, Carsten Ziegeler wrote:
Tim Larson wrote:
If it happens that 2.3 comes very soon after 2.2, then the
deprecated code in effect was just deleted and not put through a
normal deprecation cycle. Perhaps we need to also set
Joerg Heinicke wrote:
This high innovention has - at least in theory - the price of
maintaining
innovation + invention = innovention ;-)
Ah, you spotted that one. Great :)
But it's not from me:
http://disneyworld.disney.go.com/wdw/parks/attractionDetail?id=InnoventionsE
Joerg Heinicke wrote:
On 20.04.2004 12:28, Carsten Ziegeler wrote:
On the other hand I didn't get the feeling that there were many
problems when upgrading from 2.0 to 2.1. This might be due to not
upgrading at all of course.
Probably users start a project with a specific Cocoon
Unico Hommes wrote:
For my understanding, what exactly do these terms mean (i.e.
'user API'
and 'developer API') ? Are they paralel to the concepts of
'usage compatibility' and 'extension compatibility' or are
they part of a separate classification?
Yes, they are parallel. Usage
Tim Larson wrote:
I am *so* happy to see this policy being worked on :) When I
earlier proposed we write a document like this the interest
seemed minimal, so I did not push very hard. Glad to see it
is gathering steam now.
;)
Applications that write against a particular version
Joerg Heinicke wrote:
compatible to 2.2. As long as you don't use deprecated API, your
application is usage compatible across all minor versions.
Somewhat inaccurate. IMO it must read As long as you don't
use deprecated API and the API you rely on does not get
deprecated, your
I think that we might mean manifesto (noun)
... Macquarie Dictionary:
a public declaration ... of a body of persons taking
important action, making known intentions, objects,
motives, etc.; a proclamation.
Should it go into cocoon-2.1 CVS so that it travels with the
distribution, or just go into
On Thu, Apr 22, 2004 at 09:50:08PM +0200, Carsten Ziegeler wrote:
Tim Larson wrote:
If it happens that 2.3 comes very soon after 2.2, then the
deprecated code in effect was just deleted and not put
through a normal deprecation cycle. Perhaps we need to also
set a minimum length of
Message-
From: Andreas Hochsteger [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 20, 2004 10:51 PM
To: [EMAIL PROTECTED]
Subject: Re: [RT] Versions
I'm a bit confused about the naming of version number parts.
I always thought, that version numbers are constructed like this:
MAJOR.MINOR.PATCH
Carsten Ziegeler wrote:
Marc Portier wrote:
I currently don't think we have a release scheme that
supports one or the other: i.e. reality seems pretty much
like what Carsten is saying:
we just have 1,2,... 1004 (based on some gut feeling we seem
to be distributing those numbers over
Carsten,
Reads very well, I say. All we need to do is decide if that is how we
actually want to (and can) work!
One addition is to mention our policy on blocks and block status:
Blocks and Block Stability
--
Cocoon currently allows optional functionality to be included
Upayavira wrote:
Reads very well, I say. All we need to do is decide if that
is how we actually want to (and can) work!
Great! I think we could wait one more day and see if there is
some interesting feedback and then we can vote on it.
One addition is to mention our policy on blocks and
+1
- one extra: when the external lib mismatch can occur, then we should
provide that knowledge in the update docs and add a warning
-marc= (being glad he posted that arp link :-))
snip
what=the historical long mail from one eloquent Sir C. Ziegler /
--
Marc Portier
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
snip type=large /
Examples
Here are some examples to demonstrate the compatibility:
Original VersionNew VersionUsage CompatibleExtension
Compatible
2.2.3 2.2.4 Yes Yes
2.2.3
Marc Portier wrote:
Upayavira wrote:
Carsten,
Reads very well, I say. All we need to do is decide if that is how we
actually want to (and can) work!
One addition is to mention our policy on blocks and block status:
Blocks and Block Stability
--
Cocoon currently
Carsten Ziegeler wrote:
snip type=lots of good stuff/
Deprecation and Exceptions
--
To continue the Cocoon development and to keep up with the innovations,
parts of Cocoon might get deprecated; this includes parts of the user
API and also parts of the developer API.
On Wed, 2004-04-21 at 09:33, Carsten Ziegeler wrote:
snip/
External Libraries
--
Cocoon uses a set of external libraries (like for example Avalon,
Xalan or Xerces). Inbetween any release, even patch releases,
the versions of the external libraries might be updated to any
On Wed, Apr 21, 2004 at 09:33:14AM +0200, Carsten Ziegeler wrote:
The Cocoon Versioning Manifest (CVM)
This document covers how the Cocoon project is versioned.
Since Cocoon is a framework, it is very important to define
a stable API for users and
Upayavira wrote:
Marc Portier wrote:
Upayavira wrote:
Carsten,
Reads very well, I say. All we need to do is decide if that is how
we actually want to (and can) work!
One addition is to mention our policy on blocks and block status:
Blocks and Block Stability
--
On 21.04.2004 09:33, Carsten Ziegeler wrote:
Usage Compatibility
---
'Usage' compatibility guarantees that an application written
by a Cocoon user is compatible. All files developed by a typical
Cocoon user like xml files, sitemaps, stylesheets (elements and
namespace
On 20.04.2004 12:28, Carsten Ziegeler wrote:
On the other hand I didn't get the feeling that there were
many problems when upgrading from 2.0 to 2.1. This might be
due to not upgrading at all of course.
Probably users start a project with a specific Cocoon
version/the latest release at this
In [1] I suggested that we continue the development of 2.1.x and port
some nice things from the 2.2 branch back as long as they don't create
big incompatibilities.
Now, I started to port back the new environment handling and found out
that it's not that easy :)
In the current 2.2 branch we did
Carsten Ziegeler wrote:
snip/
My opinion is that we should remove deprecated classes (some of them)
in our 2.1.x branch *now* in order to create a smooth transition and
to build a better basis for the future development.
To indicate this, we should update the version number to 2.2 *now* in
the
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
snip/
My opinion is that we should remove deprecated classes (some
of them)
in our 2.1.x branch *now* in order to create a smooth
transition and to
build a better basis for the future development.
To indicate this, we should
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
snip/
My opinion is that we should remove deprecated classes (some
of them)
in our 2.1.x branch *now* in order to create a smooth
transition and to
build a better basis for the future
Carsten Ziegeler cziegeler at s-und-n.de writes:
WDYT?
Hmm, sorry, but that's to much confusion IMO. But read on ...
snip what=changes 2.1 = 2.2/
only
if we remove deprecated code, the environment handling can be
improved. Or in other words: backporting to 2.1.x would require to remove
Reinhard Poetz dijo:
IMO we can move on with 2.1.x and remove the deprecated classes if this
is necessary. WDYT?
+1
Best Regards,
Antonio Gallardo
Carsten Ziegeler wrote:
snip /
And in addition, 2.2 would be the first release with the official
cocoon forms version. This alone makes a version change acceptable.
do you already have a timeframe in mind?
(cforms is still unstable, and is IMO not near removing that tag)
WDYT?
in general I'm
Marc Portier wrote:
Carsten Ziegeler wrote:
snip /
And in addition, 2.2 would be the first release with the official
cocoon forms version. This alone makes a version change acceptable.
do you already have a timeframe in mind?
(cforms is still unstable, and is IMO not near
Carsten Ziegeler wrote:
Marc Portier wrote:
in general I'm all for a more formal description of the
meaning of versions to us.
something like: http://apr.apache.org/versioning.html but
probably more focussed towards Java classes, interfaces, xml
schema's and namespaces ?
from there we
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
snip /
IMO we can move on with 2.1.x and remove the depracated
classes if this is necessary. WDYT?
To be honest, this was my first thinking as well :) But there is
the general perception that a minor version change is 100%
compatible (or 99.9%)
Carsten Ziegeler wrote:
Joerg Heinicke wrote:
snip /
Now the confusion starts. IMO we should have clear
version/repository matchings.
Yes, a clear matching is required. We would have the clear matching
of Any cocoon version = 2.1 is in the cocoon-2.1 repository :)
LOL.
Of course, if we
Marc Portier wrote:
Hm, I think I'm swinging towards the observations you made in
opening this thread.
We seem to have grown some implicit meaning (expectations)
around these version numbers, I don't think we should ignore that...
I'm not the kind of guy that wants everything
Marc Portier wrote:
here goes:
I see some difference between what I would call 'extension'
vs. 'usage'
compatibility
snip explains/
I like the distinction and I totally agree with the vision of
'usage'. In my RT about versions I was only refering to
the 'extension' are when it comes to
: Tuesday, April 20, 2004 6:54 AM
To: [EMAIL PROTECTED]
Subject: RE: Proposal: release management guide (was Re: [RT] Versions)
I currently don't think we have a release scheme that
supports one or the other: i.e. reality seems pretty much
like what Carsten is saying:
we just have 1,2,... 1004
I'm a bit confused about the naming of version number parts.
I always thought, that version numbers are constructed like this:
MAJOR.MINOR.PATCH
I did some quick google search and found the following pages which seem
to confirm that:
http://apr.apache.org/versioning.html#strategy
36 matches
Mail list logo
