You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Emily Jiang <em...@googlemail.com> on 2011/04/06 22:51:04 UTC
semantic version packages and bundles
Am I right to say that we don't need to change the package or bundle version
on the trunk even if we change apis, as the versions will be updated when we
do a release?
I am about to commiting some api changes and would like to make sure:).
--
Thanks
Emily
=================
Emily Jiang
ejiang@apache.org
Re: semantic version packages and bundles
Posted by zoe slattery <zo...@gmail.com>.
Hi Emily - you do need to change the package version but not the bundle
version. The policy is documented here
http://aries.apache.org/development/versionpolicy.html.
You need to make changes to teh package version that reflect whatever
changes you have made to the code. At release time the release manager
will use teh changes in package versions to determine the release bundle
version.
Zoe
> Hi,
>
> Am Mittwoch, den 06.04.2011, 21:51 +0100 schrieb Emily Jiang:
>> Am I right to say that we don't need to change the package or bundle version
>> on the trunk even if we change apis, as the versions will be updated when we
>> do a release?
>> I am about to commiting some api changes and would like to make sure:).
> I am not sure about the current policy, but my POV would be to change
> the package version as you change (I hope extend not removing
> something ;-) ) the API. Depending on the RM to do this, is half the
> bill of completely forgetting it (been there, done that, unfortunately).
>
> As for bundle version: this should be increased to the next SNAPSHOT
> version number on release. So nothing to do here IMHO. This probably can
> and should be deferred until release time.
>
> Regards
> Felix
>
>
Re: semantic version packages and bundles
Posted by Jeremy Hughes <hu...@apache.org>.
On 8 April 2011 09:45, Emily Jiang <em...@googlemail.com> wrote:
> Thanks Felix. Agree. With the Aries versioning policy, it reduces the chance
> to bump
> versions too much.
>
> One question on the Aries version policy:
> In the versioning policy,
> http://aries.apache.org/development/versionpolicy.html
> , it states "*The version should relate to the most recent release of the
> package and not to the version found in trunk.*" It will be good to have
> the release version as an comment in the package.info (or an automatically
> generated package version map per release) so that the developers can
It would be good if the scripts for updating the web site [1] at the
back end of the release process could do this automatically.
In general I think we should be making things easier for a) users of
Aries b) developers c) release managers in that order.
I think adding/updating a comment in the packageinfo file to indicate
the last released version lengthens the release process, the benefit
is making things easier for developers. A script to do this would be
good.
[1] https://svn.apache.org/viewvc/aries/scripts
> immediately decide whether the package version needs to be updated. At the
> moment, developers have to look at the change histories and this process
> requires the knowledge of the last release date, which does not show in the
> change history.
>
> Thoughts?
>
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang@apache.org
>
On 7 April 2011 10:18, Felix Meschberger <fm...@gmail.com> wrote:
> Hi Emily,
>
> Am Donnerstag, den 07.04.2011, 10:09 +0100 schrieb Emily Jiang:
>> Thanks Felix fo your reply.
>>
>> The plus side for changing packaging version is not to forget it when we do
>> a release. Just one concern: we may end up increase the package version too
>> many times as each commit might end up bumping up package version when
>> changing APIs in the same package. This could make package minor or major
>> version number extremely high. For an example, we might need to end up
>> release 4.10.0 in 0.4 release while the same package number was 0.4.1 in the
>> 0.3 release. Will this cause confusion?
>>
>> Thoughts?
>
> Well, of course, a developer changing the might decide to not increase
> the version number because it has already been done before. I think the
> developer changing the API and considering upping the version number can
> invest a few minutes to verify whether it is actually required or not.
>
> On the other hands: version numbers are cheap ;-) So its probably better
> to increase too often than failing to increase ...
>
> Regards
> Felix
>
>>
>> Regards
>> Emily
>>
>> On Thu, Apr 7, 2011 at 7:55 AM, Felix Meschberger <fm...@gmail.com>wrote:
>>
>> > Hi,
>> >
>> > Am Mittwoch, den 06.04.2011, 21:51 +0100 schrieb Emily Jiang:
>> > > Am I right to say that we don't need to change the package or bundle
>> > version
>> > > on the trunk even if we change apis, as the versions will be updated when
>> > we
>> > > do a release?
>> > > I am about to commiting some api changes and would like to make sure:).
>> >
>> > I am not sure about the current policy, but my POV would be to change
>> > the package version as you change (I hope extend not removing
>> > something ;-) ) the API. Depending on the RM to do this, is half the
>> > bill of completely forgetting it (been there, done that, unfortunately).
>> >
>> > As for bundle version: this should be increased to the next SNAPSHOT
>> > version number on release. So nothing to do here IMHO. This probably can
>> > and should be deferred until release time.
>> >
>> > Regards
>> > Felix
>> >
>> >
>>
>>
>
>
>
Re: semantic version packages and bundles
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Emily,
Am Donnerstag, den 07.04.2011, 10:09 +0100 schrieb Emily Jiang:
> Thanks Felix fo your reply.
>
> The plus side for changing packaging version is not to forget it when we do
> a release. Just one concern: we may end up increase the package version too
> many times as each commit might end up bumping up package version when
> changing APIs in the same package. This could make package minor or major
> version number extremely high. For an example, we might need to end up
> release 4.10.0 in 0.4 release while the same package number was 0.4.1 in the
> 0.3 release. Will this cause confusion?
>
> Thoughts?
Well, of course, a developer changing the might decide to not increase
the version number because it has already been done before. I think the
developer changing the API and considering upping the version number can
invest a few minutes to verify whether it is actually required or not.
On the other hands: version numbers are cheap ;-) So its probably better
to increase too often than failing to increase ...
Regards
Felix
>
> Regards
> Emily
>
> On Thu, Apr 7, 2011 at 7:55 AM, Felix Meschberger <fm...@gmail.com>wrote:
>
> > Hi,
> >
> > Am Mittwoch, den 06.04.2011, 21:51 +0100 schrieb Emily Jiang:
> > > Am I right to say that we don't need to change the package or bundle
> > version
> > > on the trunk even if we change apis, as the versions will be updated when
> > we
> > > do a release?
> > > I am about to commiting some api changes and would like to make sure:).
> >
> > I am not sure about the current policy, but my POV would be to change
> > the package version as you change (I hope extend not removing
> > something ;-) ) the API. Depending on the RM to do this, is half the
> > bill of completely forgetting it (been there, done that, unfortunately).
> >
> > As for bundle version: this should be increased to the next SNAPSHOT
> > version number on release. So nothing to do here IMHO. This probably can
> > and should be deferred until release time.
> >
> > Regards
> > Felix
> >
> >
>
>
Re: semantic version packages and bundles
Posted by Emily Jiang <em...@googlemail.com>.
Thanks you Zoe pointing me to the policy. It makes more sense and solves my
concern.
Thanks
On Thu, Apr 7, 2011 at 10:09 AM, Emily Jiang <em...@googlemail.com>wrote:
> Thanks Felix fo your reply.
>
> The plus side for changing packaging version is not to forget it when we do
> a release. Just one concern: we may end up increase the package version too
> many times as each commit might end up bumping up package version when
> changing APIs in the same package. This could make package minor or major
> version number extremely high. For an example, we might need to end up
> release 4.10.0 in 0.4 release while the same package number was 0.4.1 in the
> 0.3 release. Will this cause confusion?
>
> Thoughts?
>
> Regards
> Emily
>
>
> On Thu, Apr 7, 2011 at 7:55 AM, Felix Meschberger <fm...@gmail.com>wrote:
>
>> Hi,
>>
>> Am Mittwoch, den 06.04.2011, 21:51 +0100 schrieb Emily Jiang:
>> > Am I right to say that we don't need to change the package or bundle
>> version
>> > on the trunk even if we change apis, as the versions will be updated
>> when we
>> > do a release?
>> > I am about to commiting some api changes and would like to make sure:).
>>
>> I am not sure about the current policy, but my POV would be to change
>> the package version as you change (I hope extend not removing
>> something ;-) ) the API. Depending on the RM to do this, is half the
>> bill of completely forgetting it (been there, done that, unfortunately).
>>
>> As for bundle version: this should be increased to the next SNAPSHOT
>> version number on release. So nothing to do here IMHO. This probably can
>> and should be deferred until release time.
>>
>> Regards
>> Felix
>>
>>
>
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang@apache.org
>
>
--
Thanks
Emily
=================
Emily Jiang
ejiang@apache.org
Re: semantic version packages and bundles
Posted by Emily Jiang <em...@googlemail.com>.
Thanks Felix fo your reply.
The plus side for changing packaging version is not to forget it when we do
a release. Just one concern: we may end up increase the package version too
many times as each commit might end up bumping up package version when
changing APIs in the same package. This could make package minor or major
version number extremely high. For an example, we might need to end up
release 4.10.0 in 0.4 release while the same package number was 0.4.1 in the
0.3 release. Will this cause confusion?
Thoughts?
Regards
Emily
On Thu, Apr 7, 2011 at 7:55 AM, Felix Meschberger <fm...@gmail.com>wrote:
> Hi,
>
> Am Mittwoch, den 06.04.2011, 21:51 +0100 schrieb Emily Jiang:
> > Am I right to say that we don't need to change the package or bundle
> version
> > on the trunk even if we change apis, as the versions will be updated when
> we
> > do a release?
> > I am about to commiting some api changes and would like to make sure:).
>
> I am not sure about the current policy, but my POV would be to change
> the package version as you change (I hope extend not removing
> something ;-) ) the API. Depending on the RM to do this, is half the
> bill of completely forgetting it (been there, done that, unfortunately).
>
> As for bundle version: this should be increased to the next SNAPSHOT
> version number on release. So nothing to do here IMHO. This probably can
> and should be deferred until release time.
>
> Regards
> Felix
>
>
--
Thanks
Emily
=================
Emily Jiang
ejiang@apache.org
Re: semantic version packages and bundles
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Mittwoch, den 06.04.2011, 21:51 +0100 schrieb Emily Jiang:
> Am I right to say that we don't need to change the package or bundle version
> on the trunk even if we change apis, as the versions will be updated when we
> do a release?
> I am about to commiting some api changes and would like to make sure:).
I am not sure about the current policy, but my POV would be to change
the package version as you change (I hope extend not removing
something ;-) ) the API. Depending on the RM to do this, is half the
bill of completely forgetting it (been there, done that, unfortunately).
As for bundle version: this should be increased to the next SNAPSHOT
version number on release. So nothing to do here IMHO. This probably can
and should be deferred until release time.
Regards
Felix