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 > > > > > >
