On 8 April 2011 09:45, Emily Jiang <[email protected]> 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 > [email protected] > On 7 April 2011 10:18, Felix Meschberger <[email protected]> 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 <[email protected]>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 >> > >> > >> >> > > >
