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.
On Wed, Jul 31, 2013 at 1:09 PM, Raymond Auge <[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? > > > On Wed, Jul 31, 2013 at 12:59 PM, Ferry Huberts <[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)
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
