I'll try "-baseline: *" in some test builds to see what happens. Thanks!
On Wed, Jul 31, 2013 at 1:11 PM, Raymond Auge <[email protected]>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. > > > 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) > > -- *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
