You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by zoe slattery <zo...@gmail.com> on 2011/03/16 10:20:00 UTC
[DISCUSS] Version Policy
Hi - as I work through making the changes to be able to release by
bundle we will need to start following an agreed version policy for
packages and bundles.
I've drafted something on the wiki (website). Please review it and
comment back to the list.
http://aries.apache.org/development/versionpolicy.html
Thanks, Zoë
Re: [DISCUSS] Version Policy
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Donnerstag, den 17.03.2011, 12:08 +0000 schrieb zoe slattery:
> Hi
> > Hold on: lets first clarify which version of a bundle/module you are
> > talking of:
> >
> > * If it is the bundle/module's own version as specfied along
> > with the bundle/module's groupId and artifactId.
> > This version is switched to the next SNAPSHOT version by the
> > maven release plugin
> > --> I strongly suggest to keep this mechanism as is
> OK - I had though that it was better to leave the version in trunk being
> the same as the release version - but as I work through making the
> changes I can see that this will not work. In a perfect world I think it
> would be right to do this, but as you suggested I don't think we can
> count on people remembering to change the bundle version to
> something-SNAPSHOT when they first make a change. I'm having trouble
> remembering it as I go along :-)
Right.
There is another point to make: Your users would probably be confused to
see a release version number of trunk. Release version numbers are
generally expected on (immutable) tags while trunk is considered work in
progress and should be considered "modified" right from the start.
Regards
Felix
> > * If it is the dependency version of a bundle/module the situation
> > is more interesting and is probably what you are refering to.
> >
> > In the latter (dependency) case you have two situations:
> >
> > (1) you depend on new exported functionality of the dependency. In this
> > case upgrade the dependency when you need the new exported
> > functionality.
> >
> Agreed
> > (2) you don't depend on new exported functionality: refer to the lowest
> > release version providing enough exported functionality the bundle
> > requires. This ensures the import version is automatically set correctly
> > to allow for loose coupling supported by OSGi.
> Agreed
> > Regards
> > Felix
> >
> >> There will be circumstances (maybe the majority?) when a change is made
> >> in bundle a which affects no other bundle - I guess it might be hard to
> >> remember to change the bundle version in this case.
> >>
> >> The alternative is, as you suggest, to bump the micro version and add
> >> SNAPSHOT after every release. I don't particularly mind this but it
> >> gives the release manager the job of checking ALL bundles to see what
> >> has changed and could be released, rather than just checking the ones
> >> called blah-SNAPSHOT.
> >>
> >> Zoe
> >>> In addition, as I said, the maven release plugin sets the version to
> >>> -SNAPSHOT (well, its a default and you can overwrite this in the
> >>> release:prepare goal).
> >> Yes - you can just override it. And in one sense it's completely
> >> reasonable to do so. At the point of release the code in trunk is
> >> exactly the same as that which is being released - therefore its version
> >> is logically the same.
> >>>>> Re. Bundles: I think it is solely the task of the RM to decide on the
> >>>>> version to be released. But there should be some guidelines like the
> >>>>> OSGi semantic versioning. On point to note (and extending OSGi's paper)
> >>>>> is that in Felix and Sling we generally release even versions and have
> >>>>> odd versions being SNAPSHOTs. E.g:
> >>>>>
> >>>>> x.y.1-SNAPSHOT
> >>>>> x.y.2
> >>>>> x.y.3-SNAPSHOT
> >>>>> x.y.4
> >>>>>
> >>>>> The reason for this is that x.y.z.SNAPSHOT> x.y.z in OSGi version
> >>>>> speak, which is of course not true in real life (and Maven speak).
> >>>> When would this be a problem? If a dependent module (someone else's
> >>>> for example) depends on x.y.1 in their<version> element I wouldn't
> >>>> expect maven to pick a snapshot. If it did, then a lot of release
> >>>> processes would be broken - picking snapshots instead of releases. So
> >>>> that makes me think I've misunderstood what you're saying. Can you
> >>>> expand a bit?
> >>> Its during development and using tools like Sling's JCR Install or OBR.
> >>> Remember that OBR obeys OSGi version comparison.
> >>>
> >>> In fact my proposal stems from early experience we had with OBR in
> >>> Apache Sling where bundles were not updated to release versions because
> >>> of x.y.z.SNAPSHOT> x.y.z.
> >>>
> >>> Regards
> >>> Felix
> >>>
> >>>>> FYI: This is how we do it in Sling:
> >>>>> http://sling.apache.org/site/version-policy.html.
> >>>>>
> >>>>> Regards
> >>>>> Felix
> >>>>>
> >>>>> Am Mittwoch, den 16.03.2011, 09:20 +0000 schrieb zoe slattery:
> >>>>>> Hi - as I work through making the changes to be able to release by
> >>>>>> bundle we will need to start following an agreed version policy for
> >>>>>> packages and bundles.
> >>>>>> I've drafted something on the wiki (website). Please review it and
> >>>>>> comment back to the list.
> >>>>>>
> >>>>>> http://aries.apache.org/development/versionpolicy.html
> >>>>>>
> >>>>>> Thanks, Zoë
> >>>>>
> >>>
> >
> >
>
Re: [DISCUSS] Version Policy
Posted by zoe slattery <zo...@gmail.com>.
Hi
> Hold on: lets first clarify which version of a bundle/module you are
> talking of:
>
> * If it is the bundle/module's own version as specfied along
> with the bundle/module's groupId and artifactId.
> This version is switched to the next SNAPSHOT version by the
> maven release plugin
> --> I strongly suggest to keep this mechanism as is
OK - I had though that it was better to leave the version in trunk being
the same as the release version - but as I work through making the
changes I can see that this will not work. In a perfect world I think it
would be right to do this, but as you suggested I don't think we can
count on people remembering to change the bundle version to
something-SNAPSHOT when they first make a change. I'm having trouble
remembering it as I go along :-)
> * If it is the dependency version of a bundle/module the situation
> is more interesting and is probably what you are refering to.
>
> In the latter (dependency) case you have two situations:
>
> (1) you depend on new exported functionality of the dependency. In this
> case upgrade the dependency when you need the new exported
> functionality.
>
Agreed
> (2) you don't depend on new exported functionality: refer to the lowest
> release version providing enough exported functionality the bundle
> requires. This ensures the import version is automatically set correctly
> to allow for loose coupling supported by OSGi.
Agreed
> Regards
> Felix
>
>> There will be circumstances (maybe the majority?) when a change is made
>> in bundle a which affects no other bundle - I guess it might be hard to
>> remember to change the bundle version in this case.
>>
>> The alternative is, as you suggest, to bump the micro version and add
>> SNAPSHOT after every release. I don't particularly mind this but it
>> gives the release manager the job of checking ALL bundles to see what
>> has changed and could be released, rather than just checking the ones
>> called blah-SNAPSHOT.
>>
>> Zoe
>>> In addition, as I said, the maven release plugin sets the version to
>>> -SNAPSHOT (well, its a default and you can overwrite this in the
>>> release:prepare goal).
>> Yes - you can just override it. And in one sense it's completely
>> reasonable to do so. At the point of release the code in trunk is
>> exactly the same as that which is being released - therefore its version
>> is logically the same.
>>>>> Re. Bundles: I think it is solely the task of the RM to decide on the
>>>>> version to be released. But there should be some guidelines like the
>>>>> OSGi semantic versioning. On point to note (and extending OSGi's paper)
>>>>> is that in Felix and Sling we generally release even versions and have
>>>>> odd versions being SNAPSHOTs. E.g:
>>>>>
>>>>> x.y.1-SNAPSHOT
>>>>> x.y.2
>>>>> x.y.3-SNAPSHOT
>>>>> x.y.4
>>>>>
>>>>> The reason for this is that x.y.z.SNAPSHOT> x.y.z in OSGi version
>>>>> speak, which is of course not true in real life (and Maven speak).
>>>> When would this be a problem? If a dependent module (someone else's
>>>> for example) depends on x.y.1 in their<version> element I wouldn't
>>>> expect maven to pick a snapshot. If it did, then a lot of release
>>>> processes would be broken - picking snapshots instead of releases. So
>>>> that makes me think I've misunderstood what you're saying. Can you
>>>> expand a bit?
>>> Its during development and using tools like Sling's JCR Install or OBR.
>>> Remember that OBR obeys OSGi version comparison.
>>>
>>> In fact my proposal stems from early experience we had with OBR in
>>> Apache Sling where bundles were not updated to release versions because
>>> of x.y.z.SNAPSHOT> x.y.z.
>>>
>>> Regards
>>> Felix
>>>
>>>>> FYI: This is how we do it in Sling:
>>>>> http://sling.apache.org/site/version-policy.html.
>>>>>
>>>>> Regards
>>>>> Felix
>>>>>
>>>>> Am Mittwoch, den 16.03.2011, 09:20 +0000 schrieb zoe slattery:
>>>>>> Hi - as I work through making the changes to be able to release by
>>>>>> bundle we will need to start following an agreed version policy for
>>>>>> packages and bundles.
>>>>>> I've drafted something on the wiki (website). Please review it and
>>>>>> comment back to the list.
>>>>>>
>>>>>> http://aries.apache.org/development/versionpolicy.html
>>>>>>
>>>>>> Thanks, Zoë
>>>>>
>>>
>
>
Re: [DISCUSS] Version Policy
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Mittwoch, den 16.03.2011, 20:23 +0000 schrieb zoe slattery:
> On 16/03/2011 19:28, Felix Meschberger wrote:
> > Hi,
> >
> > Am Mittwoch, den 16.03.2011, 16:49 +0000 schrieb Jeremy Hughes:
> >> On 16 March 2011 11:22, Felix Meschberger<fm...@gmail.com> wrote:
> >>> Hi,
> >>>
> >>> Good thing !
> >>>
> >>> Some remarks:
> >>>
> >>> Re. Bundles: A bundle should never exist as a non-SNAPSHOT version in
> >>> the trunk (except during the short period of time during which Maven
> >>> generates the version tag). As such immediately after a release the
> >>> bundle version switches to x.y.(z+1)-SNAPSHOT.
> >> The suggestion is to only move to x.y.(z+1)-SNAPSHOT when the first
> >> change is made to trunk. If trunk is identical to the last release,
> >> then the version in the pom is left alone.
> > Believe me, this ain't gonna work ... We are all humans and prone to
> > make mistakes, i.e. forget switching the version.
> I think it's possibly less error prone than you think. Say you have just
> made a change in bundle A, if the version is _not_ switched, Bundle B
> which depends on A will not pick up the change until the dependency
> version in B is changed _and_ the version of A is changed. This will be
> obvious quite quickly.
Hold on: lets first clarify which version of a bundle/module you are
talking of:
* If it is the bundle/module's own version as specfied along
with the bundle/module's groupId and artifactId.
This version is switched to the next SNAPSHOT version by the
maven release plugin
--> I strongly suggest to keep this mechanism as is
* If it is the dependency version of a bundle/module the situation
is more interesting and is probably what you are refering to.
In the latter (dependency) case you have two situations:
(1) you depend on new exported functionality of the dependency. In this
case upgrade the dependency when you need the new exported
functionality.
(2) you don't depend on new exported functionality: refer to the lowest
release version providing enough exported functionality the bundle
requires. This ensures the import version is automatically set correctly
to allow for loose coupling supported by OSGi.
Regards
Felix
>
> There will be circumstances (maybe the majority?) when a change is made
> in bundle a which affects no other bundle - I guess it might be hard to
> remember to change the bundle version in this case.
>
> The alternative is, as you suggest, to bump the micro version and add
> SNAPSHOT after every release. I don't particularly mind this but it
> gives the release manager the job of checking ALL bundles to see what
> has changed and could be released, rather than just checking the ones
> called blah-SNAPSHOT.
>
> Zoe
> > In addition, as I said, the maven release plugin sets the version to
> > -SNAPSHOT (well, its a default and you can overwrite this in the
> > release:prepare goal).
> Yes - you can just override it. And in one sense it's completely
> reasonable to do so. At the point of release the code in trunk is
> exactly the same as that which is being released - therefore its version
> is logically the same.
> >>> Re. Bundles: I think it is solely the task of the RM to decide on the
> >>> version to be released. But there should be some guidelines like the
> >>> OSGi semantic versioning. On point to note (and extending OSGi's paper)
> >>> is that in Felix and Sling we generally release even versions and have
> >>> odd versions being SNAPSHOTs. E.g:
> >>>
> >>> x.y.1-SNAPSHOT
> >>> x.y.2
> >>> x.y.3-SNAPSHOT
> >>> x.y.4
> >>>
> >>> The reason for this is that x.y.z.SNAPSHOT> x.y.z in OSGi version
> >>> speak, which is of course not true in real life (and Maven speak).
> >> When would this be a problem? If a dependent module (someone else's
> >> for example) depends on x.y.1 in their<version> element I wouldn't
> >> expect maven to pick a snapshot. If it did, then a lot of release
> >> processes would be broken - picking snapshots instead of releases. So
> >> that makes me think I've misunderstood what you're saying. Can you
> >> expand a bit?
> > Its during development and using tools like Sling's JCR Install or OBR.
> > Remember that OBR obeys OSGi version comparison.
> >
> > In fact my proposal stems from early experience we had with OBR in
> > Apache Sling where bundles were not updated to release versions because
> > of x.y.z.SNAPSHOT> x.y.z.
> >
> > Regards
> > Felix
> >
> >>> FYI: This is how we do it in Sling:
> >>> http://sling.apache.org/site/version-policy.html.
> >>>
> >>> Regards
> >>> Felix
> >>>
> >>> Am Mittwoch, den 16.03.2011, 09:20 +0000 schrieb zoe slattery:
> >>>> Hi - as I work through making the changes to be able to release by
> >>>> bundle we will need to start following an agreed version policy for
> >>>> packages and bundles.
> >>>> I've drafted something on the wiki (website). Please review it and
> >>>> comment back to the list.
> >>>>
> >>>> http://aries.apache.org/development/versionpolicy.html
> >>>>
> >>>> Thanks, Zoë
> >>>
> >>>
> >
> >
>
Re: [DISCUSS] Version Policy
Posted by zoe slattery <zo...@gmail.com>.
On 16/03/2011 19:28, Felix Meschberger wrote:
> Hi,
>
> Am Mittwoch, den 16.03.2011, 16:49 +0000 schrieb Jeremy Hughes:
>> On 16 March 2011 11:22, Felix Meschberger<fm...@gmail.com> wrote:
>>> Hi,
>>>
>>> Good thing !
>>>
>>> Some remarks:
>>>
>>> Re. Bundles: A bundle should never exist as a non-SNAPSHOT version in
>>> the trunk (except during the short period of time during which Maven
>>> generates the version tag). As such immediately after a release the
>>> bundle version switches to x.y.(z+1)-SNAPSHOT.
>> The suggestion is to only move to x.y.(z+1)-SNAPSHOT when the first
>> change is made to trunk. If trunk is identical to the last release,
>> then the version in the pom is left alone.
> Believe me, this ain't gonna work ... We are all humans and prone to
> make mistakes, i.e. forget switching the version.
I think it's possibly less error prone than you think. Say you have just
made a change in bundle A, if the version is _not_ switched, Bundle B
which depends on A will not pick up the change until the dependency
version in B is changed _and_ the version of A is changed. This will be
obvious quite quickly.
There will be circumstances (maybe the majority?) when a change is made
in bundle a which affects no other bundle - I guess it might be hard to
remember to change the bundle version in this case.
The alternative is, as you suggest, to bump the micro version and add
SNAPSHOT after every release. I don't particularly mind this but it
gives the release manager the job of checking ALL bundles to see what
has changed and could be released, rather than just checking the ones
called blah-SNAPSHOT.
Zoe
> In addition, as I said, the maven release plugin sets the version to
> -SNAPSHOT (well, its a default and you can overwrite this in the
> release:prepare goal).
Yes - you can just override it. And in one sense it's completely
reasonable to do so. At the point of release the code in trunk is
exactly the same as that which is being released - therefore its version
is logically the same.
>>> Re. Bundles: I think it is solely the task of the RM to decide on the
>>> version to be released. But there should be some guidelines like the
>>> OSGi semantic versioning. On point to note (and extending OSGi's paper)
>>> is that in Felix and Sling we generally release even versions and have
>>> odd versions being SNAPSHOTs. E.g:
>>>
>>> x.y.1-SNAPSHOT
>>> x.y.2
>>> x.y.3-SNAPSHOT
>>> x.y.4
>>>
>>> The reason for this is that x.y.z.SNAPSHOT> x.y.z in OSGi version
>>> speak, which is of course not true in real life (and Maven speak).
>> When would this be a problem? If a dependent module (someone else's
>> for example) depends on x.y.1 in their<version> element I wouldn't
>> expect maven to pick a snapshot. If it did, then a lot of release
>> processes would be broken - picking snapshots instead of releases. So
>> that makes me think I've misunderstood what you're saying. Can you
>> expand a bit?
> Its during development and using tools like Sling's JCR Install or OBR.
> Remember that OBR obeys OSGi version comparison.
>
> In fact my proposal stems from early experience we had with OBR in
> Apache Sling where bundles were not updated to release versions because
> of x.y.z.SNAPSHOT> x.y.z.
>
> Regards
> Felix
>
>>> FYI: This is how we do it in Sling:
>>> http://sling.apache.org/site/version-policy.html.
>>>
>>> Regards
>>> Felix
>>>
>>> Am Mittwoch, den 16.03.2011, 09:20 +0000 schrieb zoe slattery:
>>>> Hi - as I work through making the changes to be able to release by
>>>> bundle we will need to start following an agreed version policy for
>>>> packages and bundles.
>>>> I've drafted something on the wiki (website). Please review it and
>>>> comment back to the list.
>>>>
>>>> http://aries.apache.org/development/versionpolicy.html
>>>>
>>>> Thanks, Zoë
>>>
>>>
>
>
Re: [DISCUSS] Version Policy
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Mittwoch, den 16.03.2011, 16:49 +0000 schrieb Jeremy Hughes:
> On 16 March 2011 11:22, Felix Meschberger <fm...@gmail.com> wrote:
> > Hi,
> >
> > Good thing !
> >
> > Some remarks:
> >
> > Re. Bundles: A bundle should never exist as a non-SNAPSHOT version in
> > the trunk (except during the short period of time during which Maven
> > generates the version tag). As such immediately after a release the
> > bundle version switches to x.y.(z+1)-SNAPSHOT.
>
> The suggestion is to only move to x.y.(z+1)-SNAPSHOT when the first
> change is made to trunk. If trunk is identical to the last release,
> then the version in the pom is left alone.
Believe me, this ain't gonna work ... We are all humans and prone to
make mistakes, i.e. forget switching the version.
In addition, as I said, the maven release plugin sets the version to
-SNAPSHOT (well, its a default and you can overwrite this in the
release:prepare goal).
>
> >
> > Re. Bundles: I think it is solely the task of the RM to decide on the
> > version to be released. But there should be some guidelines like the
> > OSGi semantic versioning. On point to note (and extending OSGi's paper)
> > is that in Felix and Sling we generally release even versions and have
> > odd versions being SNAPSHOTs. E.g:
> >
> > x.y.1-SNAPSHOT
> > x.y.2
> > x.y.3-SNAPSHOT
> > x.y.4
> >
> > The reason for this is that x.y.z.SNAPSHOT > x.y.z in OSGi version
> > speak, which is of course not true in real life (and Maven speak).
>
> When would this be a problem? If a dependent module (someone else's
> for example) depends on x.y.1 in their <version> element I wouldn't
> expect maven to pick a snapshot. If it did, then a lot of release
> processes would be broken - picking snapshots instead of releases. So
> that makes me think I've misunderstood what you're saying. Can you
> expand a bit?
Its during development and using tools like Sling's JCR Install or OBR.
Remember that OBR obeys OSGi version comparison.
In fact my proposal stems from early experience we had with OBR in
Apache Sling where bundles were not updated to release versions because
of x.y.z.SNAPSHOT > x.y.z.
Regards
Felix
>
> >
> > FYI: This is how we do it in Sling:
> > http://sling.apache.org/site/version-policy.html.
> >
> > Regards
> > Felix
> >
> > Am Mittwoch, den 16.03.2011, 09:20 +0000 schrieb zoe slattery:
> >> Hi - as I work through making the changes to be able to release by
> >> bundle we will need to start following an agreed version policy for
> >> packages and bundles.
> >> I've drafted something on the wiki (website). Please review it and
> >> comment back to the list.
> >>
> >> http://aries.apache.org/development/versionpolicy.html
> >>
> >> Thanks, Zoë
> >
> >
> >
Re: [DISCUSS] Version Policy
Posted by Jeremy Hughes <hu...@apache.org>.
On 16 March 2011 11:22, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> Good thing !
>
> Some remarks:
>
> Re. Bundles: A bundle should never exist as a non-SNAPSHOT version in
> the trunk (except during the short period of time during which Maven
> generates the version tag). As such immediately after a release the
> bundle version switches to x.y.(z+1)-SNAPSHOT.
The suggestion is to only move to x.y.(z+1)-SNAPSHOT when the first
change is made to trunk. If trunk is identical to the last release,
then the version in the pom is left alone.
>
> Re. Bundles: I think it is solely the task of the RM to decide on the
> version to be released. But there should be some guidelines like the
> OSGi semantic versioning. On point to note (and extending OSGi's paper)
> is that in Felix and Sling we generally release even versions and have
> odd versions being SNAPSHOTs. E.g:
>
> x.y.1-SNAPSHOT
> x.y.2
> x.y.3-SNAPSHOT
> x.y.4
>
> The reason for this is that x.y.z.SNAPSHOT > x.y.z in OSGi version
> speak, which is of course not true in real life (and Maven speak).
When would this be a problem? If a dependent module (someone else's
for example) depends on x.y.1 in their <version> element I wouldn't
expect maven to pick a snapshot. If it did, then a lot of release
processes would be broken - picking snapshots instead of releases. So
that makes me think I've misunderstood what you're saying. Can you
expand a bit?
>
> FYI: This is how we do it in Sling:
> http://sling.apache.org/site/version-policy.html.
>
> Regards
> Felix
>
> Am Mittwoch, den 16.03.2011, 09:20 +0000 schrieb zoe slattery:
>> Hi - as I work through making the changes to be able to release by
>> bundle we will need to start following an agreed version policy for
>> packages and bundles.
>> I've drafted something on the wiki (website). Please review it and
>> comment back to the list.
>>
>> http://aries.apache.org/development/versionpolicy.html
>>
>> Thanks, Zoë
>
>
>
Re: [DISCUSS] Version Policy
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Mittwoch, den 16.03.2011, 14:30 +0000 schrieb zoe slattery:
> Hi Felix - thanks
> >
> > Re. Bundles: A bundle should never exist as a non-SNAPSHOT version in
> > the trunk (except during the short period of time during which Maven
> > generates the version tag). As such immediately after a release the
> > bundle version switches to x.y.(z+1)-SNAPSHOT.
> What is the thinking behind this? Is it a Maven thing? I thought it
> would be a convenient way to tell at a glance if something had changed
> or not.
Yes, it is basically a maven thing: The Maven Release plugin does this
automatically after tagging the release.
The goal is to not get different builds with the same version. This
would confuse not just downstream users ...
Trunk should always be -SNAPSHOT.
> If we can't just have no "SNAPSHOT" could we use something like
> DEV-SNAPSHOT (ie no version) in trunk?
What's the problem of trunk being -SNAPSHOT ?
Regards
Felix
> > Re. Bundles: I think it is solely the task of the RM to decide on the
> > version to be released.
> Yes - that was my view too.
> > But there should be some guidelines like the
> > OSGi semantic versioning. On point to note (and extending OSGi's paper)
> > is that in Felix and Sling we generally release even versions and have
> > odd versions being SNAPSHOTs. E.g:
> >
> > x.y.1-SNAPSHOT
> > x.y.2
> > x.y.3-SNAPSHOT
> > x.y.4
> >
> > The reason for this is that x.y.z.SNAPSHOT> x.y.z in OSGi version
> > speak, which is of course not true in real life (and Maven speak).
> Ah - I see. That's an interesting approach.
> > FYI: This is how we do it in Sling:
> > http://sling.apache.org/site/version-policy.html.
> >
> > Regards
> > Felix
> >
> > Am Mittwoch, den 16.03.2011, 09:20 +0000 schrieb zoe slattery:
> >> Hi - as I work through making the changes to be able to release by
> >> bundle we will need to start following an agreed version policy for
> >> packages and bundles.
> >> I've drafted something on the wiki (website). Please review it and
> >> comment back to the list.
> >>
> >> http://aries.apache.org/development/versionpolicy.html
> >>
> >> Thanks, Zoë
> >
> >
>
Re: [DISCUSS] Version Policy
Posted by zoe slattery <zo...@gmail.com>.
Hi Felix - thanks
>
> Re. Bundles: A bundle should never exist as a non-SNAPSHOT version in
> the trunk (except during the short period of time during which Maven
> generates the version tag). As such immediately after a release the
> bundle version switches to x.y.(z+1)-SNAPSHOT.
What is the thinking behind this? Is it a Maven thing? I thought it
would be a convenient way to tell at a glance if something had changed
or not.
If we can't just have no "SNAPSHOT" could we use something like
DEV-SNAPSHOT (ie no version) in trunk?
> Re. Bundles: I think it is solely the task of the RM to decide on the
> version to be released.
Yes - that was my view too.
> But there should be some guidelines like the
> OSGi semantic versioning. On point to note (and extending OSGi's paper)
> is that in Felix and Sling we generally release even versions and have
> odd versions being SNAPSHOTs. E.g:
>
> x.y.1-SNAPSHOT
> x.y.2
> x.y.3-SNAPSHOT
> x.y.4
>
> The reason for this is that x.y.z.SNAPSHOT> x.y.z in OSGi version
> speak, which is of course not true in real life (and Maven speak).
Ah - I see. That's an interesting approach.
> FYI: This is how we do it in Sling:
> http://sling.apache.org/site/version-policy.html.
>
> Regards
> Felix
>
> Am Mittwoch, den 16.03.2011, 09:20 +0000 schrieb zoe slattery:
>> Hi - as I work through making the changes to be able to release by
>> bundle we will need to start following an agreed version policy for
>> packages and bundles.
>> I've drafted something on the wiki (website). Please review it and
>> comment back to the list.
>>
>> http://aries.apache.org/development/versionpolicy.html
>>
>> Thanks, Zoë
>
>
Re: [DISCUSS] Version Policy
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Good thing !
Some remarks:
Re. Bundles: A bundle should never exist as a non-SNAPSHOT version in
the trunk (except during the short period of time during which Maven
generates the version tag). As such immediately after a release the
bundle version switches to x.y.(z+1)-SNAPSHOT.
Re. Bundles: I think it is solely the task of the RM to decide on the
version to be released. But there should be some guidelines like the
OSGi semantic versioning. On point to note (and extending OSGi's paper)
is that in Felix and Sling we generally release even versions and have
odd versions being SNAPSHOTs. E.g:
x.y.1-SNAPSHOT
x.y.2
x.y.3-SNAPSHOT
x.y.4
The reason for this is that x.y.z.SNAPSHOT > x.y.z in OSGi version
speak, which is of course not true in real life (and Maven speak).
FYI: This is how we do it in Sling:
http://sling.apache.org/site/version-policy.html.
Regards
Felix
Am Mittwoch, den 16.03.2011, 09:20 +0000 schrieb zoe slattery:
> Hi - as I work through making the changes to be able to release by
> bundle we will need to start following an agreed version policy for
> packages and bundles.
> I've drafted something on the wiki (website). Please review it and
> comment back to the list.
>
> http://aries.apache.org/development/versionpolicy.html
>
> Thanks, Zoë