On 31/07/13 19:11, Raymond Auge wrote: > Also, I would imagine for the initial behavior to only be build warnings > that a developer may be breaking provider/consumer backward > compatibility. I want to grow our team's awareness around the idea of > semantic versionning... not make them want to quit. >
Come see my talk at EclipseCon, if it's accepted ;-) > > On Wed, Jul 31, 2013 at 1:09 PM, Raymond Auge <[email protected] > <mailto:[email protected]>> wrote: > > 1) We can't use BNDTools! (again our project is a MASSIVE well > established build that hundreds of developers are consuming from a > variety of IDEs, and that can't change). > 2) we are using bnd to build our jars from ant (been doing so for > around 1 year) > 3) this is not version 1.0 of the product or of the consumers of our > APIs. We're at version 6.2.0 (and people often refer to the API > versions as the version of the product so I don't want to change all > that legacy verbiage). > > My logic is assuming we "tagged" version 6.2.0 with that package > version for everything when we do our current release (in fact just > after the release and before any other changes are made), every > subsequent source change would be calculated against that particular > version. > > Make sense? > For (semantic) versioning in OSGi the bundle version actually is meaningless. It's a marketing number, so 6.2.0 in your case. Only package versions have meaning. Of course you can always version everything the same, but a single major change will bump _everything_ to 7.0.0. I hope you're aware of that... > > On Wed, Jul 31, 2013 at 12:59 PM, Ferry Huberts <[email protected] > <mailto:[email protected]>> wrote: > > > > On 31/07/13 18:25, Raymond Auge wrote: > > Hello all, > > > > I was wondering if anyone ever created a tool that would > "review" a > > project source, and based on a single initially supplied > version, apply > > package versionning to the sources (including detection of > > consumers/providers). > > > > Our project has tens of thousands of classes and I'm trying to > bootstrap > > initial versionning. > > > > Note that I fully realize that such tools are likely to make wrong > > assumptions particularly where it's unclear about "internal" > > implementation details (private packages). > > > > > I'm not really sure what you're asking, but if you had no > version before > than the initial version will be 1.0.0. Otherwise you'd need to > compare > the previous released version of the bundle with the bundle that is > built from the source tree. bnd can do that for you, it has a diff > command that shows the diff and suggests a new version. > bndtools can also do that for you automatically.... > > You can use the release tooling of bnd/bndtools to set up all > versions. > > If you install our latest stable build from > > https://bndtools.ci.cloudbees.com/job/bndtools.master/lastSuccessfulBuild/artifact/build/generated/p2/ > then you can enable baselining (a work in progress) to manage > all versions. > > The baselining will account for provider/consumer types and many > more cases. > > Enabling baselining is done by adding '-baseline: *' to the bnd > file. > > > > -- > Ferry Huberts > > > > > -- > *Raymond Augé* > <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) > Senior Software Architect > *Liferay, Inc.* <http://www.liferay.com> (@Liferay) > > > > > -- > *Raymond Augé* > <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) > Senior Software Architect > *Liferay, Inc.* <http://www.liferay.com> (@Liferay) > -- Ferry Huberts _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
