You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Felix Meschberger <fm...@gmail.com> on 2008/01/03 13:21:28 UTC
Thoughts towards an initial release
Hi all,
I have been thinking about releases and version numbers in Sling and
wrote up an initial text on that at [1].
The page is currently missing the actual list of bundles, we would want
to include in the initial release. This is something, which still has to
be defined.
WDYT ?
Regards
Felix
[1] http://cwiki.apache.org/SLING/thoughts-on-release-management.html
Re: Thoughts towards an initial release
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Sonntag, den 06.01.2008, 20:46 +0200 schrieb Jukka Zitting:
> Hi,
>
> On Jan 6, 2008 8:26 PM, Felix Meschberger <fm...@gmail.com> wrote:
> > Version comparison is in terms of comparing each version part to each
> > other. The numeric parts are compared as would be expected. The
> > qualifier part is compared with string comparsion, where of course "" is
> > smaller than "SNAPSHOT".
>
> How about replacing "SNAPSHOT" with something like "STABLE" whenever
> releasing a component? That way we'd only need to play tricks with the
> qualifier part and avoid messing with release numbering.
This could of course also be a solution. But it also looks uncommon.
Also, I would like to reserve the qualifier for real release
qualification (maybe a build number ???) in the future.
Regards
Felix
Re: Thoughts towards an initial release
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Jan 6, 2008 8:26 PM, Felix Meschberger <fm...@gmail.com> wrote:
> Version comparison is in terms of comparing each version part to each
> other. The numeric parts are compared as would be expected. The
> qualifier part is compared with string comparsion, where of course "" is
> smaller than "SNAPSHOT".
How about replacing "SNAPSHOT" with something like "STABLE" whenever
releasing a component? That way we'd only need to play tricks with the
qualifier part and avoid messing with release numbering.
Just an idea, I'm not opposed to Felix' proposal.
BR,
Jukka Zitting
Re: Thoughts towards an initial release
Posted by pi...@wasabicowboy.com.
Makes sense, +1 for me on the scheme.
Paddy
Sent via BlackBerry from T-Mobile
-----Original Message-----
From: Felix Meschberger <fm...@gmail.com>
Date: Sun, 06 Jan 2008 19:26:24
To:sling-dev@incubator.apache.org
Subject: Re: Thoughts towards an initial release
Hi,
The OSGi core spec defines the Version as a quadruple 1.2.3.string. The
first three parts are numeric and called major, minor and micro version
number. The fourth part is a string (with a limited character set) which
is called the qualifier.
Version comparison is in terms of comparing each version part to each
other. The numeric parts are compared as would be expected. The
qualifier part is compared with string comparsion, where of course "" is
smaller than "SNAPSHOT".
This is where the problem starts: The (per maven) released version 2.0.0
is actually smaller than 2.0.0.SNAPSHOT in OSGi terms. That means, a
SNAPSHOT version will always be considered more recent in OSGi term than
the corresponding released version.
That is why I suggest this seemingly odd micro version flipping.
Hope this helps clarifying.
Regards
Felix
Am Freitag, den 04.01.2008, 12:03 -0800 schrieb Padraic Hannon:
> I only have a couple comments based on the wiki and email threads.
>
> > The Apache Felix Maven Bundle Plugin we use to build the Sling
> bundles converts Maven version numbers
> > to correct OSGi version numbers. For example, the version 2.0.0-
> incubator-SNAPSHOT is converted to
> > 2.0.0.incubator-SNAPSHOT.
>
> Why not just keep the names the same? Both end in -SNAPSHOT which
> seems to satisfy the maven pattern.
>
> On the jackrabbit project 1.4-SNAPSHOT becomes 1.4 at release and a
> new release is started, this is a nice simple model. However, in your
> model we have this even/odd flip. The issue, I guess, is that OSGI
> wants 1.2.3.4.String and not 1.2.3.4-String? What if we always have
> 1.2.3.4.incubator-SNAPSHOT which gets promoted to 1.2.3.4? Do the
> semantics of 1.2.3.4.dev-SNAPSHOT state that it is newer than 1.2.3.4
> since it is a revision of that which gives rise to the need for a
> revision flip? The problem I see is in speaking of a release, for
> example, if we are all working on release 2.0 we would be checking out
> version 1.9.incubator-SNAPSHOT which is a bit confusing no? Is the
> problem with going from 2.0.incubator-SNAPSHOT to 2.0 a problem with
> OSGi recognizing the .incubator-SNAPSHOT release as newer than 2.0 or
> is it purely a human thing? If a human thing I think it is
> understandable that 2.0 would be the release version whereas
> the .incubator-SNAPSHOT release is not. Perhaps (assuming that this
> isn't a problem for the OSGi container) we could use the word .dev-
> SNAPSHOT or something to be more clear.
>
> -paddy
>
Re: Moving MicroSling to Sling
Posted by Padraic Hannon <pi...@wasabicowboy.com>.
Sorry I missed the creation of SLING-149. I'll start taking a look at
that.
-paddy
On Jan 7, 2008, at 9:47 AM, Padraic Hannon wrote:
>
> On Jan 7, 2008, at 5:51 AM, Bertrand Delacretaz wrote:
>
>>
>> Agreed, and hopefully porting the µsling stuff to Sling, as was
>> decided late last year, will help in providing an easy to use
>> "getting
>> started" app and examples. I intend to start working on this Real
>> Soon
>> Now.
>>
>
> If you'd like to map out how, in general, this might look, I would
> be more than happy to start work on it.
>
> -paddy
Moving MicroSling to Sling
Posted by Padraic Hannon <pi...@wasabicowboy.com>.
On Jan 7, 2008, at 5:51 AM, Bertrand Delacretaz wrote:
>
> Agreed, and hopefully porting the µsling stuff to Sling, as was
> decided late last year, will help in providing an easy to use "getting
> started" app and examples. I intend to start working on this Real Soon
> Now.
>
If you'd like to map out how, in general, this might look, I would be
more than happy to start work on it.
-paddy
Re: Thoughts towards an initial release
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Jan 6, 2008 11:57 PM, Robert Biernat
<Ro...@objectconsulting.com.au> wrote:
> ...As someone who has only been following this project for a short amount of time I think before a
> release is done a better sample application needs to be produced along with some documentation
> that explains how web development with Sling differs to traditional web development....
Agreed, and hopefully porting the µsling stuff to Sling, as was
decided late last year, will help in providing an easy to use "getting
started" app and examples. I intend to start working on this Real Soon
Now.
Apart from that, I agree with
http://cwiki.apache.org/SLING/thoughts-on-release-management.html
-Bertrand
[1] http://markmail.org/message/atbjzjjp2wflkotb
Re: Thoughts towards an initial release
Posted by J Aaron Farr <fa...@apache.org>.
"Robert Biernat" <Ro...@objectconsulting.com.au> writes:
> Hi,
>
> As someone who has only been following this project for a short
> amount of time I think before a release is done a better sample
> application needs to be produced along with some documentation that
> explains how web development with Sling differs to traditional web
> development.
Also, with my 'mentor' hat on, this sort of documentation is critical
for developing a larger user/developer community. Whether before the
release or after, it should be on the roadmap.
Otherwise, things look good.
--
J Aaron Farr jadetower.com [US] +1 724-964-4515
馮傑仁 cubiclemuses.com [HK] +852 8123-7905
Re: Thoughts towards an initial release
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote:
> Yes, the initial release breaks the rules in two aspects: The SNAPSHOT
> is even and it will encompass almost everything :-)
>
> Of course we could turn back the current release numbers to
> 1.9.9-incubtator-SNAPSHOT and then comply with the concept... But I am
> not sure, whether it is worth the effort.
I was not brave enough to suggest this :)
(No, it's not worth it)
>
> I can think, that we could well live with this minor inconsistency.
Yes, sure.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Thoughts towards an initial release
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Montag, den 07.01.2008, 17:45 +0100 schrieb Carsten Ziegeler:
> I'm wondering when we follow the supposed version guide if our current
> versions are correct: 2.0.0-incubator-snapshot uses an even micro
> version, but it should be an odd one (as it is a snapshot) :)
>
> So it seems that we have to break the rule for an initial release :)
Yes, the initial release breaks the rules in two aspects: The SNAPSHOT
is even and it will encompass almost everything :-)
Of course we could turn back the current release numbers to
1.9.9-incubtator-SNAPSHOT and then comply with the concept... But I am
not sure, whether it is worth the effort.
I can think, that we could well live with this minor inconsistency.
WDYT ?
Regards
Felix
Re: Thoughts towards an initial release
Posted by Carsten Ziegeler <cz...@apache.org>.
I'm wondering when we follow the supposed version guide if our current
versions are correct: 2.0.0-incubator-snapshot uses an even micro
version, but it should be an odd one (as it is a snapshot) :)
So it seems that we have to break the rule for an initial release :)
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
RE: Thoughts towards an initial release
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Rob,
Am Montag, den 07.01.2008, 09:57 +1100 schrieb Robert Biernat:
> As someone who has only been following this project for a short amount of time I think before a release is done a better sample application needs to be produced along with some documentation that explains how web development with Sling differs to traditional web development.
I completely agree, that we have to extend our sample application and
turn it into some more usefull thing. And also we desperately need to
extend and enhance our documentation, part of which is really outdated
after some rounds of refactorings.
And we are working on these issues :-) But as always in the Apache
world, resources are limited and everyone is invited to contribute !
Nevertheless, I would like to not block any releases for lack of
serious, enterprise level documentation. OTOH, we are not actually just
before a release, but I would like to start the thinking for the first
release to come in the near future.
Regards
Felix
RE: Thoughts towards an initial release
Posted by Robert Biernat <Ro...@objectconsulting.com.au>.
Hi,
As someone who has only been following this project for a short amount of time I think before a release is done a better sample application needs to be produced along with some documentation that explains how web development with Sling differs to traditional web development.
Rob
________________________________
From: Felix Meschberger [mailto:fmeschbe@gmail.com]
Sent: Mon 7/01/2008 5:26 AM
To: sling-dev@incubator.apache.org
Subject: Re: Thoughts towards an initial release
Hi,
The OSGi core spec defines the Version as a quadruple 1.2.3.string. The
first three parts are numeric and called major, minor and micro version
number. The fourth part is a string (with a limited character set) which
is called the qualifier.
Version comparison is in terms of comparing each version part to each
other. The numeric parts are compared as would be expected. The
qualifier part is compared with string comparsion, where of course "" is
smaller than "SNAPSHOT".
This is where the problem starts: The (per maven) released version 2.0.0
is actually smaller than 2.0.0.SNAPSHOT in OSGi terms. That means, a
SNAPSHOT version will always be considered more recent in OSGi term than
the corresponding released version.
That is why I suggest this seemingly odd micro version flipping.
Hope this helps clarifying.
Regards
Felix
Am Freitag, den 04.01.2008, 12:03 -0800 schrieb Padraic Hannon:
> I only have a couple comments based on the wiki and email threads.
>
> > The Apache Felix Maven Bundle Plugin we use to build the Sling
> bundles converts Maven version numbers
> > to correct OSGi version numbers. For example, the version 2.0.0-
> incubator-SNAPSHOT is converted to
> > 2.0.0.incubator-SNAPSHOT.
>
> Why not just keep the names the same? Both end in -SNAPSHOT which
> seems to satisfy the maven pattern.
>
> On the jackrabbit project 1.4-SNAPSHOT becomes 1.4 at release and a
> new release is started, this is a nice simple model. However, in your
> model we have this even/odd flip. The issue, I guess, is that OSGI
> wants 1.2.3.4.String and not 1.2.3.4-String? What if we always have
> 1.2.3.4.incubator-SNAPSHOT which gets promoted to 1.2.3.4? Do the
> semantics of 1.2.3.4.dev-SNAPSHOT state that it is newer than 1.2.3.4
> since it is a revision of that which gives rise to the need for a
> revision flip? The problem I see is in speaking of a release, for
> example, if we are all working on release 2.0 we would be checking out
> version 1.9.incubator-SNAPSHOT which is a bit confusing no? Is the
> problem with going from 2.0.incubator-SNAPSHOT to 2.0 a problem with
> OSGi recognizing the .incubator-SNAPSHOT release as newer than 2.0 or
> is it purely a human thing? If a human thing I think it is
> understandable that 2.0 would be the release version whereas
> the .incubator-SNAPSHOT release is not. Perhaps (assuming that this
> isn't a problem for the OSGi container) we could use the word .dev-
> SNAPSHOT or something to be more clear.
>
> -paddy
>
Re: Thoughts towards an initial release
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
The OSGi core spec defines the Version as a quadruple 1.2.3.string. The
first three parts are numeric and called major, minor and micro version
number. The fourth part is a string (with a limited character set) which
is called the qualifier.
Version comparison is in terms of comparing each version part to each
other. The numeric parts are compared as would be expected. The
qualifier part is compared with string comparsion, where of course "" is
smaller than "SNAPSHOT".
This is where the problem starts: The (per maven) released version 2.0.0
is actually smaller than 2.0.0.SNAPSHOT in OSGi terms. That means, a
SNAPSHOT version will always be considered more recent in OSGi term than
the corresponding released version.
That is why I suggest this seemingly odd micro version flipping.
Hope this helps clarifying.
Regards
Felix
Am Freitag, den 04.01.2008, 12:03 -0800 schrieb Padraic Hannon:
> I only have a couple comments based on the wiki and email threads.
>
> > The Apache Felix Maven Bundle Plugin we use to build the Sling
> bundles converts Maven version numbers
> > to correct OSGi version numbers. For example, the version 2.0.0-
> incubator-SNAPSHOT is converted to
> > 2.0.0.incubator-SNAPSHOT.
>
> Why not just keep the names the same? Both end in -SNAPSHOT which
> seems to satisfy the maven pattern.
>
> On the jackrabbit project 1.4-SNAPSHOT becomes 1.4 at release and a
> new release is started, this is a nice simple model. However, in your
> model we have this even/odd flip. The issue, I guess, is that OSGI
> wants 1.2.3.4.String and not 1.2.3.4-String? What if we always have
> 1.2.3.4.incubator-SNAPSHOT which gets promoted to 1.2.3.4? Do the
> semantics of 1.2.3.4.dev-SNAPSHOT state that it is newer than 1.2.3.4
> since it is a revision of that which gives rise to the need for a
> revision flip? The problem I see is in speaking of a release, for
> example, if we are all working on release 2.0 we would be checking out
> version 1.9.incubator-SNAPSHOT which is a bit confusing no? Is the
> problem with going from 2.0.incubator-SNAPSHOT to 2.0 a problem with
> OSGi recognizing the .incubator-SNAPSHOT release as newer than 2.0 or
> is it purely a human thing? If a human thing I think it is
> understandable that 2.0 would be the release version whereas
> the .incubator-SNAPSHOT release is not. Perhaps (assuming that this
> isn't a problem for the OSGi container) we could use the word .dev-
> SNAPSHOT or something to be more clear.
>
> -paddy
>
Re: Thoughts towards an initial release
Posted by Padraic Hannon <ph...@edmunds.com>.
I only have a couple comments based on the wiki and email threads.
> The Apache Felix Maven Bundle Plugin we use to build the Sling
bundles converts Maven version numbers
> to correct OSGi version numbers. For example, the version 2.0.0-
incubator-SNAPSHOT is converted to
> 2.0.0.incubator-SNAPSHOT.
Why not just keep the names the same? Both end in -SNAPSHOT which
seems to satisfy the maven pattern.
On the jackrabbit project 1.4-SNAPSHOT becomes 1.4 at release and a
new release is started, this is a nice simple model. However, in your
model we have this even/odd flip. The issue, I guess, is that OSGI
wants 1.2.3.4.String and not 1.2.3.4-String? What if we always have
1.2.3.4.incubator-SNAPSHOT which gets promoted to 1.2.3.4? Do the
semantics of 1.2.3.4.dev-SNAPSHOT state that it is newer than 1.2.3.4
since it is a revision of that which gives rise to the need for a
revision flip? The problem I see is in speaking of a release, for
example, if we are all working on release 2.0 we would be checking out
version 1.9.incubator-SNAPSHOT which is a bit confusing no? Is the
problem with going from 2.0.incubator-SNAPSHOT to 2.0 a problem with
OSGi recognizing the .incubator-SNAPSHOT release as newer than 2.0 or
is it purely a human thing? If a human thing I think it is
understandable that 2.0 would be the release version whereas
the .incubator-SNAPSHOT release is not. Perhaps (assuming that this
isn't a problem for the OSGi container) we could use the word .dev-
SNAPSHOT or something to be more clear.
-paddy
Re: Thoughts towards an initial release
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Alexander,
Am Freitag, den 04.01.2008, 15:20 +0100 schrieb Alexander Saar:
> > On short term, we might well create assemblies for them. Good proposals
> > for creation of such assemblies are welcome, of course :-)
> >
>
> What do you mean with creation? If you refer to identification of
> bundles that can be deployed together I think this should be done with
> some integration tests (or test suite) which can be tested against
> different combinations of bundle versions.
Ehrm, didn't find the correct word ... Yes the task is identifying which
bundles should be combined to what assemblies (or deployment packages in
the future). This IMHO has nothing to do with integration testing and
test suites, its just a definition of which bundles belong together - if
at all possible.
Regards
Felix
Re: Thoughts towards an initial release
Posted by Alexander Saar <al...@googlemail.com>.
Hi,
Felix Meschberger schrieb:
>> I think the versioning scheme is OK, as it supports the needed requirements.
>>
>> I very much like the idea of just releasing single bundles, as it allows
>> faster bug fixing and improvement/enhancement of funtionality. But from
>> a user perspective it should be ensured that there are regular releases
>> of webapp and standalone app. On the one hand this allows releasing of a
>> set of bundles wich are ensured to work together. On the other hand it
>> prevents users that start with sling in one or two years from starting
>> with an old sling version and installing all new bundles again.
>>
>
> Agreed. This is why it says: "For convenience we may create standalone
> and web application releases once or twice a year. These applications
> though would just be packagings of already released bundles." :-)
>
I've seen it. Just wanted to point out that this is important for users
of sling :-)
>> BTW, is there a way to define a set of bundles which certainly work
>> together. Can this be done with the assembly feature? If so we could
>> just release assemblies containing newest sling bundles once or twice a
>> year.
>>
>
> Basically yes, but: The OSGi Compendium 1.4 has a Deployment Admin
> Specification which defines a deployment package file format and and
> respective administrative API. In the Apache Felix project we are
> currently waiting for the paper work to be finished for a contribution
> of an implementation of that specification. As soon as that one is in
> Apache Felix, we might well provide Deployment Packages of Sling
> Bundles.
>
Sounds great! Relying on standards for deployment is the best way for
future compatibility with other OSGi implementations or if someone would
like to combine sling with other code that can be deployed as bundles.
> On short term, we might well create assemblies for them. Good proposals
> for creation of such assemblies are welcome, of course :-)
>
What do you mean with creation? If you refer to identification of
bundles that can be deployed together I think this should be done with
some integration tests (or test suite) which can be tested against
different combinations of bundle versions.
Regards,
Alex
Re: Thoughts towards an initial release
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Freitag, den 04.01.2008, 14:50 +0100 schrieb Alexander Saar:
> I think the versioning scheme is OK, as it supports the needed requirements.
>
> I very much like the idea of just releasing single bundles, as it allows
> faster bug fixing and improvement/enhancement of funtionality. But from
> a user perspective it should be ensured that there are regular releases
> of webapp and standalone app. On the one hand this allows releasing of a
> set of bundles wich are ensured to work together. On the other hand it
> prevents users that start with sling in one or two years from starting
> with an old sling version and installing all new bundles again.
Agreed. This is why it says: "For convenience we may create standalone
and web application releases once or twice a year. These applications
though would just be packagings of already released bundles." :-)
>
> BTW, is there a way to define a set of bundles which certainly work
> together. Can this be done with the assembly feature? If so we could
> just release assemblies containing newest sling bundles once or twice a
> year.
Basically yes, but: The OSGi Compendium 1.4 has a Deployment Admin
Specification which defines a deployment package file format and and
respective administrative API. In the Apache Felix project we are
currently waiting for the paper work to be finished for a contribution
of an implementation of that specification. As soon as that one is in
Apache Felix, we might well provide Deployment Packages of Sling
Bundles.
On short term, we might well create assemblies for them. Good proposals
for creation of such assemblies are welcome, of course :-)
Regards
Felix
>
> Regards
> Alex
>
>
> Felix Meschberger schrieb:
> > Hi all,
> >
> > I have been thinking about releases and version numbers in Sling and
> > wrote up an initial text on that at [1].
> >
> > The page is currently missing the actual list of bundles, we would want
> > to include in the initial release. This is something, which still has to
> > be defined.
> >
> > WDYT ?
> >
> > Regards
> > Felix
> >
> > [1] http://cwiki.apache.org/SLING/thoughts-on-release-management.html
> >
> >
>
Re: Thoughts towards an initial release
Posted by Alexander Saar <al...@googlemail.com>.
I think the versioning scheme is OK, as it supports the needed requirements.
I very much like the idea of just releasing single bundles, as it allows
faster bug fixing and improvement/enhancement of funtionality. But from
a user perspective it should be ensured that there are regular releases
of webapp and standalone app. On the one hand this allows releasing of a
set of bundles wich are ensured to work together. On the other hand it
prevents users that start with sling in one or two years from starting
with an old sling version and installing all new bundles again.
BTW, is there a way to define a set of bundles which certainly work
together. Can this be done with the assembly feature? If so we could
just release assemblies containing newest sling bundles once or twice a
year.
Regards
Alex
Felix Meschberger schrieb:
> Hi all,
>
> I have been thinking about releases and version numbers in Sling and
> wrote up an initial text on that at [1].
>
> The page is currently missing the actual list of bundles, we would want
> to include in the initial release. This is something, which still has to
> be defined.
>
> WDYT ?
>
> Regards
> Felix
>
> [1] http://cwiki.apache.org/SLING/thoughts-on-release-management.html
>
>
Re: Thoughts towards an initial release
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote:
> Am Freitag, den 04.01.2008, 13:34 +0100 schrieb Carsten Ziegeler:
>> I like the versioning scheme.
>>
>> I have one question regarding branches, you write:
>>
>> "For branching, the branch always gets an incremented micro version
>> number. For example when branching off _2.1.1-SNAPSHOT_ the branch
>> version would be _2.2.1-SNAPSHOT_."
>>
>> The text says increasing the micro version while the minor version is
>> increased in the sample. Which one do you mean?
>
> Oops. This is an error, I meant to say "an incremented minor version
> number". The example is correct. I'll fix it in the text. Thanks.
>
Ah, ok :)
Now, I think we should just leave branching out for the moment as we
might not need it. We should avoid branches whenever possible. And if we
need it, I can imagine that we decide on a per case basis what the
versions of the branch and trunk will be.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Thoughts towards an initial release
Posted by Felix Meschberger <fm...@gmail.com>.
Am Freitag, den 04.01.2008, 13:34 +0100 schrieb Carsten Ziegeler:
> I like the versioning scheme.
>
> I have one question regarding branches, you write:
>
> "For branching, the branch always gets an incremented micro version
> number. For example when branching off _2.1.1-SNAPSHOT_ the branch
> version would be _2.2.1-SNAPSHOT_."
>
> The text says increasing the micro version while the minor version is
> increased in the sample. Which one do you mean?
Oops. This is an error, I meant to say "an incremented minor version
number". The example is correct. I'll fix it in the text. Thanks.
Regards
Felix
>
> Carsten
>
> Felix Meschberger wrote:
> > Hi all,
> >
> > I have been thinking about releases and version numbers in Sling and
> > wrote up an initial text on that at [1].
> >
> > The page is currently missing the actual list of bundles, we would want
> > to include in the initial release. This is something, which still has to
> > be defined.
> >
> > WDYT ?
> >
> > Regards
> > Felix
> >
> > [1] http://cwiki.apache.org/SLING/thoughts-on-release-management.html
> >
> >
>
>
Re: Thoughts towards an initial release
Posted by Carsten Ziegeler <cz...@apache.org>.
I like the versioning scheme.
I have one question regarding branches, you write:
"For branching, the branch always gets an incremented micro version
number. For example when branching off _2.1.1-SNAPSHOT_ the branch
version would be _2.2.1-SNAPSHOT_."
The text says increasing the micro version while the minor version is
increased in the sample. Which one do you mean?
Carsten
Felix Meschberger wrote:
> Hi all,
>
> I have been thinking about releases and version numbers in Sling and
> wrote up an initial text on that at [1].
>
> The page is currently missing the actual list of bundles, we would want
> to include in the initial release. This is something, which still has to
> be defined.
>
> WDYT ?
>
> Regards
> Felix
>
> [1] http://cwiki.apache.org/SLING/thoughts-on-release-management.html
>
>
--
Carsten Ziegeler
cziegeler@apache.org