Guava as OSGi bundles (aka Eclipse plugin)
632 views
Skip to first unread message
Mikaël
Dec 7, 2010, 6:34:49 AM12/7/10
to guava-discuss
Hi all,
I created a project to host guava packaging for OSGi (http://
code.google.com/a/eclipselabs.org/p/guava-bundle/) ! This is a set of
bash scripts that takes a release of guava and packages it as an OSGi
bundle. Therefore, it is pretty straightforward to add a new release.
The result is a P2 repository (aka Eclipse update site) with all
metadata filled (version, licences, branding, copyright...). It is
available at the following address :
http://svn.codespot.com/a/eclipselabs.org/guava-bundle/trunk/repository/
The repository provides SDK (with sources and Javadoc) and Runtime
(binary only) features for all binary releases of Guava (r03 -> r07).
The packaged Jars are individually available from the "plugins" sub
folder.
I know there is project called "guava-osgi" that aims to do the same
thing, but the author never replies to my contribution proposal
(http://code.google.com/p/guava-osgi/issues/detail?id=3) to his
project.
As noted on the homepage of the project, Guava follows a simple
incremental numbering scheme for its releases versionning (r03, r04,
r05...). As OSGi needs a finest level of details for versionning, the
packing project "guava-bundle" mapped this scheme as follow:
* A Guava release rX where X is the integral version number of the
release will be available in guava-bundle 1.X.0
For instance, the r05 release is available in the bundle with version
number 1.5.0.
All OSGi metadata are synchronized with this version number mapping:
* Bundles (aka plugins) versions,
* Exported packages versions,
* Features versions
Hope this will be usefull to some people. Also, I would be glad to
contribute the packaging scripts to the guava team if they are
interested.
Best regards,
Mikael
I created a project to host guava packaging for OSGi (http://
code.google.com/a/eclipselabs.org/p/guava-bundle/) ! This is a set of
bash scripts that takes a release of guava and packages it as an OSGi
bundle. Therefore, it is pretty straightforward to add a new release.
The result is a P2 repository (aka Eclipse update site) with all
metadata filled (version, licences, branding, copyright...). It is
available at the following address :
http://svn.codespot.com/a/eclipselabs.org/guava-bundle/trunk/repository/
The repository provides SDK (with sources and Javadoc) and Runtime
(binary only) features for all binary releases of Guava (r03 -> r07).
The packaged Jars are individually available from the "plugins" sub
folder.
I know there is project called "guava-osgi" that aims to do the same
thing, but the author never replies to my contribution proposal
(http://code.google.com/p/guava-osgi/issues/detail?id=3) to his
project.
As noted on the homepage of the project, Guava follows a simple
incremental numbering scheme for its releases versionning (r03, r04,
r05...). As OSGi needs a finest level of details for versionning, the
packing project "guava-bundle" mapped this scheme as follow:
* A Guava release rX where X is the integral version number of the
release will be available in guava-bundle 1.X.0
For instance, the r05 release is available in the bundle with version
number 1.5.0.
All OSGi metadata are synchronized with this version number mapping:
* Bundles (aka plugins) versions,
* Exported packages versions,
* Features versions
Hope this will be usefull to some people. Also, I would be glad to
contribute the packaging scripts to the guava team if they are
interested.
Best regards,
Mikael
Robert Konigsberg
Dec 8, 2010, 10:11:05 PM12/8/10
to Mikaël, guava-discuss
Hi Mikaël,
I also made an attempt at managing Guava bundles (see http://konigsberg.blogspot.com/2010/04/guava-as-osgi-bundle.html) but only made one version. I didn't script it, which now I realize was the way to go. I also neglected to grab guava-osgi@eclipselabs because I hadn't committed to doing the legwork (but do have of guava-osgi@googlecode.) But again, if I had thought about making it scriptable... I just HATE the work required to go from plug-in to update site. Even for One Lousy Plug-in. How many plug-ins have I written that went nowhere because I needed an update site? Too many.
I looked at the repository a little bit... where are your scripts? I see that you have written some templates, though I think at the moment you give credit to Google as the bundle provider, which I think is strictly speaking incorrect. I'm no lawyer, nor open source muckity-muck, but I think right now you're the provider.
But that doesn't mean integrating this with guava isn't unreasonable. But before taking something like that on, I'd recommend getting some adoption. I think your way of doing things is good, certainly better than mine, and more likely to make your project successful.
What do you think?
-Rob
Mikaël
Dec 9, 2010, 3:54:21 AM12/9/10
to guava-discuss
Hi Rob,
My answers below.
> I also made an attempt at managing Guava bundles (seehttp://konigsberg.blogspot.com/2010/04/guava-as-osgi-bundle.html) but only
> made one version.
I did notice your attempt and was sad that you did not continue post
r03. That was the main motivation for me to create the guava-bundle
project (http://code.google.com/a/eclipselabs.org/p/guava-bundle/).
> I didn't script it, which now I realize was the way to go.
Thank you :)
> I also neglected to grab guava-osgi@eclipselabs because I hadn't committed
> to doing the legwork (but do have of guava-osgi@googlecode.) But again, if
> I had thought about making it scriptable... I just HATE the work required to
> go from plug-in to update site. Even for One Lousy Plug-in. How many
> plug-ins have I written that went nowhere because I needed an update site?
> Too many.
I understand. This is a pain in the neck to do the packaging work, but
it is also the only way to offer ready-to-use app/API/...
> I looked at the repository a little bit... where are your scripts?
The scripts are now contained in a single file :
http://code.google.com/a/eclipselabs.org/p/guava-bundle/source/browse/trunk/build.sh
> I see
> that you have written some templates, though I think at the moment you give
> credit to Google as the bundle provider, which I think is strictly speaking
> incorrect. I'm no lawyer, nor open source muckity-muck, but I think right
> now you're the provider.
Yeah, templates are a lazy trick to avoid me to create everything from
the scripts. About the "Bundle-Vendor", I filled it with "Google Inc."
because I really did no addition/modificaiton to the bundle and then,
think it was more honest. But it is an issue for the guava team, I'm
ok to change it to anything else ("Eclipselabs.org for instance").
> But that doesn't mean integrating this with guava isn't unreasonable. But
> before taking something like that on, I'd recommend getting some adoption. I
> think your way of doing things is good, certainly better than mine, and more
> likely to make your project successful.
Thank you for your advices. Adoption is certainly the best criteria to
evaluate the relevance of integration. I was just posting to let
people know it exists, and you and the guava team are free to use it
the way you want !
Best regards,
Mikael
My answers below.
> I also made an attempt at managing Guava bundles (seehttp://konigsberg.blogspot.com/2010/04/guava-as-osgi-bundle.html) but only
> made one version.
I did notice your attempt and was sad that you did not continue post
r03. That was the main motivation for me to create the guava-bundle
project (http://code.google.com/a/eclipselabs.org/p/guava-bundle/).
> I didn't script it, which now I realize was the way to go.
> I also neglected to grab guava-osgi@eclipselabs because I hadn't committed
> to doing the legwork (but do have of guava-osgi@googlecode.) But again, if
> I had thought about making it scriptable... I just HATE the work required to
> go from plug-in to update site. Even for One Lousy Plug-in. How many
> plug-ins have I written that went nowhere because I needed an update site?
> Too many.
it is also the only way to offer ready-to-use app/API/...
> I looked at the repository a little bit... where are your scripts?
http://code.google.com/a/eclipselabs.org/p/guava-bundle/source/browse/trunk/build.sh
> I see
> that you have written some templates, though I think at the moment you give
> credit to Google as the bundle provider, which I think is strictly speaking
> incorrect. I'm no lawyer, nor open source muckity-muck, but I think right
> now you're the provider.
the scripts. About the "Bundle-Vendor", I filled it with "Google Inc."
because I really did no addition/modificaiton to the bundle and then,
think it was more honest. But it is an issue for the guava team, I'm
ok to change it to anything else ("Eclipselabs.org for instance").
> But that doesn't mean integrating this with guava isn't unreasonable. But
> before taking something like that on, I'd recommend getting some adoption. I
> think your way of doing things is good, certainly better than mine, and more
> likely to make your project successful.
evaluate the relevance of integration. I was just posting to let
people know it exists, and you and the guava team are free to use it
the way you want !
Best regards,
Mikael
Holger Hoffstätte
Dec 9, 2010, 6:15:08 AM12/9/10
to guava-discuss
For some reason my previous reply never seemed to make it..
On Dec 7, 12:34 pm, Mikaël <mikael.barb...@gmail.com> wrote:
> * A Guava release rX where X is the integral version number of the
> release will be available in guava-bundle 1.X.0
This seems a bit wrong to me (and not only to me). Until Guava has
reached "release 1.0" status, it should not be exported with 1.0 since
that will break later imports & exports. My/our own Guava bundle
exports r0x releases as version 0.x for precisely that reason.
For myself I used the maven-bundle-plugin and just re-publish as
com.google.guava artifactId into the same groupId. Obviously it would
make most sense to add this to the existing ant build, using bnd. IIRC
there's a bug open for just that.
Has there been any statement whether Guava will ever reach "1.0"? The
bug tracker contains many issues marked as "post-1.0", which makes
little sense to me otherwise.
cheers
-h
On Dec 7, 12:34 pm, Mikaël <mikael.barb...@gmail.com> wrote:
> * A Guava release rX where X is the integral version number of the
> release will be available in guava-bundle 1.X.0
reached "release 1.0" status, it should not be exported with 1.0 since
that will break later imports & exports. My/our own Guava bundle
exports r0x releases as version 0.x for precisely that reason.
For myself I used the maven-bundle-plugin and just re-publish as
com.google.guava artifactId into the same groupId. Obviously it would
make most sense to add this to the existing ant build, using bnd. IIRC
there's a bug open for just that.
Has there been any statement whether Guava will ever reach "1.0"? The
bug tracker contains many issues marked as "post-1.0", which makes
little sense to me otherwise.
cheers
-h
Mikaël
Dec 9, 2010, 7:27:44 AM12/9/10
to guava-discuss
Hi Holger,
My answers below.
> This seems a bit wrong to me (and not only to me). Until Guava has
> reached "release 1.0" status, it should not be exported with 1.0 since
> that will break later imports & exports.
In fact, I read nowhere that the guava team wil follow a qualified
version numbering X.X.X. AFAIK, guava is considered stable (for API
without @Beta annotation) since r03 and then, from my point of view,
deserves 1.X.X OSGi version number.
Whatever, the fact is that both mappings (yours and mine) are wrong in
regard to the OSGi specification which stated that the versionning
scheme (in the form of Major.Minor.Micro) must follow those rules:
the 'Major' segment (the first) will change for non-backwards-
compatible changes;
the 'Minor' segment (the middle) will change for feature enhancements
that are backwards compatible;
the 'Micro' segment (the last) will change for bug-fixes that do not
produce visible feature changes.
It means that the OSGi packaging of guava should be decoupled from the
tagging of the release. Each release should be analysed to see how far
it is compatible/incompatible with the previous one. From this
analysis, only the right version segment should be incremented ! It is
a lack of simplicity and clarity from my point of view, then I chose
one that seems reasonable to me.
> For myself I used the maven-bundle-plugin and just re-publish as
> com.google.guava artifactId into the same groupId. Obviously it would
> make most sense to add this to the existing ant build, using bnd. IIRC
> there's a bug open for just that.
I would be glad if it is integrated. But, the other need that is
addressed by my project is not only to provide guava as an OSGi bundle
but also a P2 repository (aka eclipse update site) which is not
provided by the "maven-bundle-plugin" build kind AFAIK.
> Has there been any statement whether Guava will ever reach "1.0"? The
> bug tracker contains many issues marked as "post-1.0", which makes
> little sense to me otherwise.
It is stated very clearly in this thread in an answer by Kevin
http://groups.google.com/group/guava-discuss/browse_thread/thread/8f430f563ded3ad9/0c82d2501ff63b4a
"""
>> -We don't know what 03, 04, 05, and so on means. Is it a major
>> release? Is it just a minor?
Where do you look to try to find this answer for other libraries --
how do
you find out what *they* think constitutes a major release versus a
minor
release? How could we communicate this to users? Guava doesn't have
major
or minor releases, just releases.
"""
Best regards,
Mikael
My answers below.
> This seems a bit wrong to me (and not only to me). Until Guava has
> reached "release 1.0" status, it should not be exported with 1.0 since
> that will break later imports & exports.
version numbering X.X.X. AFAIK, guava is considered stable (for API
without @Beta annotation) since r03 and then, from my point of view,
deserves 1.X.X OSGi version number.
Whatever, the fact is that both mappings (yours and mine) are wrong in
regard to the OSGi specification which stated that the versionning
scheme (in the form of Major.Minor.Micro) must follow those rules:
the 'Major' segment (the first) will change for non-backwards-
compatible changes;
the 'Minor' segment (the middle) will change for feature enhancements
that are backwards compatible;
the 'Micro' segment (the last) will change for bug-fixes that do not
produce visible feature changes.
It means that the OSGi packaging of guava should be decoupled from the
tagging of the release. Each release should be analysed to see how far
it is compatible/incompatible with the previous one. From this
analysis, only the right version segment should be incremented ! It is
a lack of simplicity and clarity from my point of view, then I chose
one that seems reasonable to me.
> For myself I used the maven-bundle-plugin and just re-publish as
> com.google.guava artifactId into the same groupId. Obviously it would
> make most sense to add this to the existing ant build, using bnd. IIRC
> there's a bug open for just that.
addressed by my project is not only to provide guava as an OSGi bundle
but also a P2 repository (aka eclipse update site) which is not
provided by the "maven-bundle-plugin" build kind AFAIK.
> Has there been any statement whether Guava will ever reach "1.0"? The
> bug tracker contains many issues marked as "post-1.0", which makes
> little sense to me otherwise.
http://groups.google.com/group/guava-discuss/browse_thread/thread/8f430f563ded3ad9/0c82d2501ff63b4a
"""
>> -We don't know what 03, 04, 05, and so on means. Is it a major
>> release? Is it just a minor?
Where do you look to try to find this answer for other libraries --
how do
you find out what *they* think constitutes a major release versus a
minor
release? How could we communicate this to users? Guava doesn't have
major
or minor releases, just releases.
"""
Best regards,
Mikael
Robert Konigsberg
Dec 9, 2010, 8:22:13 AM12/9/10
to Mikaël, guava-discuss
Oh, wait, I am the one who didn't contact you? Gah! Sorry! Let me hopefully give some explanation: in August I was on leave of absence, and I had lost all interest in coding. I wanted to spend the rest of my summer leave doing Not Very Much. So I do apologize.
> I looked at the repository a little bit... where are your scripts?The scripts are now contained in a single file :
http://code.google.com/a/eclipselabs.org/p/guava-bundle/source/browse/trunk/build.sh
Yeah, templates are a lazy trick to avoid me to create everything from
the scripts. About the "Bundle-Vendor", I filled it with "Google Inc."
because I really did no addition/modificaiton to the bundle and then,
think it was more honest. But it is an issue for the guava team, I'm
ok to change it to anything else ("Eclipselabs.org for instance").
Tell you what: go look at the org.junit bundle and see who is listed as the provider.
I will review your stuff a little more, and yes, if you are still interested, I'll make you an owner of guava-osgi.
Robert Konigsberg
konig...@gmail.com
Holger Hoffstätte
Dec 9, 2010, 8:38:12 AM12/9/10
to guava-discuss
On Dec 9, 1:27 pm, Mikaël <mikael.barb...@gmail.com> wrote:
> Whatever, the fact is that both mappings (yours and mine) are wrong in
> regard to the OSGi specification which stated that the versionning
Oh, I know and understand :). The real underlying problem here is of
> Whatever, the fact is that both mappings (yours and mine) are wrong in
> regard to the OSGi specification which stated that the versionning
course that a) Guava is deviating from established practices and b) we
have to interpret what they don't clearly spell out anywhere.
> It means that the OSGi packaging of guava should be decoupled from the
> tagging of the release. Each release should be analysed to see how far
> it is compatible/incompatible with the previous one. From this
proper versioning & modularity in the first place. "A little bit
incompatible" sounds just like "a little bit pregnant". If you really
want to go through with that approach you need to go full-force and
provide fine-grained per-package versioning instead of "globally" on
the level of a released jar.
Of course all this would be much easier if guava wouldn't be a single
monolithic blob for no good reason.
> I would be glad if it is integrated. But, the other need that is
> addressed by my project is not only to provide guava as an OSGi bundle
> but also a P2 repository (aka eclipse update site) which is not
> provided by the "maven-bundle-plugin" build kind AFAIK.
metadata in the regular jar. Just forcing people to create more
artifact versions with arbitrary semantics in randomly different
places creates huge maintenance efforts for everyone.
Also P2 is only useful for P2 users, whereas proper metadata in the
regular ant/maven artifact will reach a much bigger audience. Once OBR
is finalized this will be even more relevant.
> > Has there been any statement whether Guava will ever reach "1.0"? The
> > bug tracker contains many issues marked as "post-1.0", which makes
> > little sense to me otherwise.
>
> It is stated very clearly in this thread in an answer by Kevin:
I cannot see anything about bug tracking, or what "post-1.0" is
supposed to mean when there will never be a 1.0. My understanding from
the google-collections->guava migration was always that the r-releases
were temporary until the non-collection packages had stabilized. If
that's not the case any longer - fine. Still doesn't help us picking
an official versioning scheme.
cheers
-h
Mikaël Barbero
Dec 9, 2010, 9:24:44 AM12/9/10
to guava-discuss
Oups, forgot to reply to the list...
Mikaël
--
Mikaël Barbero
cell.+33 6 42 02 80 39
---------- Forwarded message ----------
From: Mikaël Barbero <mikael....@gmail.com>
Date: 2010/12/9
Subject: Re: [guava] Re: Guava as OSGi bundles (aka Eclipse plugin)
To: Robert Konigsberg <konig...@gmail.com>
From: Mikaël Barbero <mikael....@gmail.com>
Date: 2010/12/9
Subject: Re: [guava] Re: Guava as OSGi bundles (aka Eclipse plugin)
To: Robert Konigsberg <konig...@gmail.com>
On Thu, Dec 9, 2010 at 14:22, Robert Konigsberg <konig...@gmail.com> wrote:
Oh, wait, I am the one who didn't contact you? Gah! Sorry! Let me hopefully give some explanation: in August I was on leave of absence, and I had lost all interest in coding. I wanted to spend the rest of my summer leave doing Not Very Much. So I do apologize.
Yes you are this guys :) You're welcome, I do not blame you for that ! In August, I was just trying not to duplicate efforts but I can understand the need for a break in digital life !
Tell you what: go look at the org.junit bundle and see who is listed as the provider.
You're true. Bundle-Vendor should specify who build the bundle and not who is the copyright owner of the content. I'll fix that ASAP.
I will review your stuff a little more, and yes, if you are still interested, I'll make you an owner of guava-osgi.
Thanks for the review and your proposal. I'm still interrested but we should discuss how and where our two project should be merged not to confuse our users.
Best regards,
--
Mikaël Barbero
cell.+33 6 42 02 80 39
Mikaël Barbero
Dec 9, 2010, 9:25:16 AM12/9/10
to guava-discuss
Oups, forgot to reply to the list...
---------- Forwarded message ----------
From: Mikaël Barbero <mikael....@gmail.com>
Date: 2010/12/9
Subject: Re: [guava] Re: Guava as OSGi bundles (aka Eclipse plugin)
From: Mikaël Barbero <mikael....@gmail.com>
Date: 2010/12/9
Subject: Re: [guava] Re: Guava as OSGi bundles (aka Eclipse plugin)
To: Holger Hoffstätte <holger.ho...@googlemail.com>
From my point of view, projects are free to use their own versioning scheme. There are so many around that I don't think there is one single truth (remember the trolls about OSGi / Jigsaw's JSR).
The work on Guava are impressive and I can understand that the guava team don't want to bother with how to satisfy part of the community with a versioning scheme that is specific to OSGi only. They made and justified choices that make senses and we have to live with that.
Don't misinterpret, I'm big fan of the OSGi versioning scheme (and I use Eclipse PDE tools to check it on my projects). The white paper about semantic versioning (http://semver.org/) is full of sense, but I can't force people to follow it.
Despite of this fact, I chose not to respect my guidelines to be more understandable to the users of my bundles. They can identify quickly that the bundle 1.6.0 comes from r06.
For every other remarks, I'll let answer guys from the guava team but I'm afraid we 'll have to live in a heterogeneous world forever...
Best regards,
Mikael
2010/12/9 Holger Hoffstätte <holger.ho...@googlemail.com>
--
guava-...@googlegroups.com.
http://groups.google.com/group/guava-discuss?hl=en
unsubscribe: guava-discus...@googlegroups.com
This list is for discussion; for help, post to Stack Overflow instead:
http://stackoverflow.com/questions/ask
Use the tag "guava".
Tatu Saloranta
Dec 9, 2010, 12:14:40 PM12/9/10
to guava-...@googlegroups.com
2010/12/9 Mikaël Barbero <mikael....@gmail.com>:
> Oups, forgot to reply to the list...
>
> ---------- Forwarded message ----------
> From: Mikaël Barbero <mikael....@gmail.com>
> Date: 2010/12/9
> Subject: Re: [guava] Re: Guava as OSGi bundles (aka Eclipse plugin)
> To: Holger Hoffstätte <holger.ho...@googlemail.com>
>
>
> From my point of view, projects are free to use their own versioning scheme.
> There are so many around that I don't think there is one single truth
> (remember the trolls about OSGi / Jigsaw's JSR).
> Oups, forgot to reply to the list...
>
> ---------- Forwarded message ----------
> From: Mikaël Barbero <mikael....@gmail.com>
> Date: 2010/12/9
> Subject: Re: [guava] Re: Guava as OSGi bundles (aka Eclipse plugin)
> To: Holger Hoffstätte <holger.ho...@googlemail.com>
>
>
> From my point of view, projects are free to use their own versioning scheme.
> There are so many around that I don't think there is one single truth
> (remember the trolls about OSGi / Jigsaw's JSR).
While this may true, the scheme used by guava project is rather
unusual and it is quite hard to say it follows an established
generally used pattern; or even tries to play it nice with ones that
are established. OSGi scheme for example is quite close to Apache
versioning and the idea of versioning reflecting compatibility changes
is not very controversial at this point.
So in that sense I do think criticism is fair; even though projects
are obviously free to choose whatever versioning system (including
none at all) they choose to.
But at this point it would be good to hear from core guava committers
what their view is, and how versioning is planned to work in future.
> The work on Guava are impressive and I can understand that the guava team
> don't want to bother with how to satisfy part of the community with a
> versioning scheme that is specific to OSGi only. They made and justified
This is just speculation until someone from the project team confirms
this view. Perhaps there are good explanations for choosing current
scheme.
I don't think versioning issues dissussed are "OSGi only" either.
Other commonly used schemes have similar hierarchic structure (APR,
versioning of linux kernels or most other OSes), and would map much
more nicely to OSGi as well as versioning that Maven uses.
Maven use case is especially important since guava is a low-level
dependency of many projects; and very useful component at that.
> choices that make senses and we have to live with that.
> Don't misinterpret, I'm big fan of the OSGi versioning scheme (and I use
> Eclipse PDE tools to check it on my projects). The white paper about
> semantic versioning (http://semver.org/) is full of sense, but I can't force
> people to follow it.
I don't think anyone is trying to force a scheme, but to work on
finding suitable mapping that allows translation; and to ensure
everyone understands issues.
There is also nothing wrong in trying to convince owners of the
project to improve things based on usability and compatibility
concerns. My experience with open source project owners is that they
are willing to listen to differing viewpoints and make good decisions
for the community; not always ones others request, but generally ones
where requests are at least acknowledged.
-+ Tatu +-
Kevin Bourrillion
Dec 9, 2010, 1:02:28 PM12/9/10
to Tatu Saloranta, guava-...@googlegroups.com
On Thu, Dec 9, 2010 at 9:14 AM, Tatu Saloranta <tsalo...@gmail.com> wrote:
While this may true, the scheme used by guava project is rather
unusual and it is quite hard to say it follows an established
generally used pattern; or even tries to play it nice with ones that
are established.
We have the absolute simplest versioning scheme imaginable. After release 7, the next release is release 8. 43 releases after that will be release 51. We've said in the past that anyone who would rather consider release 8 to be be release "8.0" is perfectly welcome to do that. Because of the nature of the @Beta subset of our library, every release can introduce incompatibilities. And for the non-@Beta majority, incompatibilities can appear in the form of deleted deprecated methods on a rolling basis (a method can be removed after 18 months of deprecation).
The way all this works is the end result of a lot of careful consideration over the last several years, and I still believe there is no other (necessarily more complex) versioning scheme that makes any sense for us.
But at this point it would be good to hear from core guava committers
what their view is, and how versioning is planned to work in future.
Exactly how it does (as just covered).
--
Kevin Bourrillion @ Google
http://guava-libraries.googlecode.com
Kevin Bourrillion
Dec 9, 2010, 1:45:17 PM12/9/10
to Holger Hoffstätte, guava-discuss
On Thu, Dec 9, 2010 at 3:15 AM, Holger Hoffstätte <holger.ho...@googlemail.com> wrote:
Has there been any statement whether Guava will ever reach "1.0"? The
bug tracker contains many issues marked as "post-1.0", which makes
little sense to me otherwise.
If you look at the entire history of a bug that dates back to the Google Collections era, then yes, you'll see that. Those bugs were imported from that project into this one. No bugs have that tag anymore, not even closed ones.
I cannot see anything about bug tracking, or what "post-1.0" is
supposed to mean when there will never be a 1.0. My understanding from
the google-collections->guava migration was always that the r-releases
were temporary until the non-collection packages had stabilized.
There is no more concept of an entire package stabilizing as a whole. That notion made releasing the "Google Collections Library", at the level of quality it has, incredibly painful. Now, as each individual class or method stabilizes, it loses its @Beta tag; that's it.
Chris Povirk
Dec 12, 2010, 1:31:40 PM12/12/10
to mikael....@gmail.com, guava-...@googlegroups.com
>> While this may true, the scheme used by guava project is rather
>> unusual and it is quite hard to say it follows an established
>> generally used pattern; or even tries to play it nice with ones that
>> are established.
>
> We have the absolute simplest versioning scheme imaginable. After release
> 7, the next release is release 8. 43 releases after that will be release
> 51. We've said in the past that anyone who would rather consider release 8
> to be be release "8.0" is perfectly welcome to do that. Because of the
> nature of the @Beta subset of our library, every release can introduce
> incompatibilities. And for the non-@Beta majority, incompatibilities can
> appear in the form of deleted deprecated methods on a rolling basis (a
> method can be removed after 18 months of deprecation).
>> unusual and it is quite hard to say it follows an established
>> generally used pattern; or even tries to play it nice with ones that
>> are established.
>
> We have the absolute simplest versioning scheme imaginable. After release
> 7, the next release is release 8. 43 releases after that will be release
> 51. We've said in the past that anyone who would rather consider release 8
> to be be release "8.0" is perfectly welcome to do that. Because of the
> nature of the @Beta subset of our library, every release can introduce
> incompatibilities. And for the non-@Beta majority, incompatibilities can
> appear in the form of deleted deprecated methods on a rolling basis (a
> method can be removed after 18 months of deprecation).
> Whatever, the fact is that both mappings (yours and mine) are wrong in
> regard to the OSGi specification which stated that the versionning
> scheme (in the form of Major.Minor.Micro) must follow those rules:
> the 'Major' segment (the first) will change for non-backwards-
> compatible changes;
> the 'Minor' segment (the middle) will change for feature enhancements
> that are backwards compatible;
> the 'Micro' segment (the last) will change for bug-fixes that do not
> produce visible feature changes.
> Whatever, the fact is that both mappings (yours and mine) are wrong in
> regard to the OSGi specification which stated that the versionning
> scheme (in the form of Major.Minor.Micro) must follow those rules:
> the 'Major' segment (the first) will change for non-backwards-
> compatible changes;
> the 'Minor' segment (the middle) will change for feature enhancements
> that are backwards compatible;
> the 'Micro' segment (the last) will change for bug-fixes that do not
> produce visible feature changes.
Pulling all this together, I think that mapping v1 to 1.0, v2 to 2.0,
... is the right choice. It follows OSGi rules better than 1.1, 1.2,
... (or 0.1, 0.2, ...), the only other straightforward mapping scheme.
Taking the v1, v2, ... versioning scheme as given, does this sound
reasonable?
Mikaël Barbero
Dec 13, 2010, 3:40:35 AM12/13/10
to Chris Povirk, guava-...@googlegroups.com
On Sun, Dec 12, 2010 at 19:31, Chris Povirk <cpo...@google.com> wrote:
>> While this may true, the scheme used by guava project is rather
>> unusual and it is quite hard to say it follows an established
>> generally used pattern; or even tries to play it nice with ones that
>> are established.
>
> We have the absolute simplest versioning scheme imaginable. After release
> 7, the next release is release 8. 43 releases after that will be release
> 51. We've said in the past that anyone who would rather consider release 8
> to be be release "8.0" is perfectly welcome to do that. Because of the
> nature of the @Beta subset of our library, every release can introduce
> incompatibilities. And for the non-@Beta majority, incompatibilities can
> appear in the form of deleted deprecated methods on a rolling basis (a
> method can be removed after 18 months of deprecation).
> Whatever, the fact is that both mappings (yours and mine) are wrong in
> regard to the OSGi specification which stated that the versionning
> scheme (in the form of Major.Minor.Micro) must follow those rules:
> the 'Major' segment (the first) will change for non-backwards-
> compatible changes;
> the 'Minor' segment (the middle) will change for feature enhancements
> that are backwards compatible;
> the 'Micro' segment (the last) will change for bug-fixes that do not
> produce visible feature changes.
Pulling all this together, I think that mapping v1 to 1.0, v2 to 2.0,
... is the right choice. It follows OSGi rules better than 1.1, 1.2,
... (or 0.1, 0.2, ...), the only other straightforward mapping scheme.
Taking the v1, v2, ... versioning scheme as given, does this sound
reasonable?
Best regards,
Mikael
Reply all
Reply to author
Forward
0 new messages