Just adding a packageinfo (or package-info.java) would help and would not cost
anything. For the Consumer/Provider types ... well, I do not see an easy
solution but would be curious to hear your experiences when you try Andrei
Pozolotin <[email protected]>'s application at
https://github.com/barchart/barchart-version-tester.
I know people think it is confusing to start at 1.0.0 but notice that starting
at your current version is MUCH more confusing the day after tomorrow. I.e. you
make all packages 6.2.0 and now tomorrow half is at 7.0.0, and a quarter is at
6.3.0 while your product is still 6.2.1. Packages will evolve very differently
over time. One way to make it clean a package version is -completely- unrelated
to a bundle version is to start at a very high number, e.g. 100.0.0. For OSGi,
there is no compatibility between major versions so it is ok to start anywhere.
There is also another reason not to confuse a product version with package
versions. The marketing girls want to own that number and get very freakish
when you try to deny them their whims. The usually don't care about package
versions ...
So I do understand your point but understand what future pain you will be
causing.
Good luck and keep us posted about your experiences. Kind regards,
Peter Kriens
On 31 jul. 2013, at 21:02, Raymond Auge wrote:
> Thanks all,
>
> I guess what I was really after was a tool which would actually create all
> the packageinfo files for me so I wouldn't have to add them to the hundreds
> and hundreds of unversioned packages.
>
> I can script it.
>
>
> On Wed, Jul 31, 2013 at 2:56 PM, Ferry Huberts <[email protected]> wrote:
>
>
> On 31/07/13 19:23, Raymond Auge wrote:
> >
> > On Wed, Jul 31, 2013 at 1:15 PM, Ferry Huberts <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> > 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...
> >
> >
> > Yeah, I surely understand that... but I want to start from something
> > that makes sense! Starting at 1.0 will confuse everyone who has been
> > consuming our produce for years.
> >
> > I'm also not suggesting that we would just update all the package
> > versions to the same value... that would be pointless.
> >
> > I'm certainly taking about "baselining" the initial versions, just not
> > with 1.0.
>
> Then just start with the versions from where you are now ;-)
> No problem for the (our) tooling
>
> PS. it's a work in progress, if you find issues, please report them
> (although it should work quite well already)
>
> >
> > --
> > *Raymond Augé*
> > <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
> > Senior Software Architect
> > *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
> >
>
> --
> Ferry Huberts
>
>
>
> --
> Raymond Augé (@rotty3000)
> Senior Software Architect
> Liferay, Inc. (@Liferay)
>
>
>
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
