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 <[email protected]>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 <[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 >> >> > > > -- > Thanks > Emily > ================= > Emily Jiang > [email protected] > > -- Thanks Emily ================= Emily Jiang [email protected]
