When comes a productive version of guave?

[els]

Before a few weeks I want to use the google collections in our
company. Our problem is, since the collections project is moved to the
guave project there are a few things which are not really usable for a
productive system. For example the @Beta annotation, or there is no
source package etc.

Is there an outlook for a released version of the guave project as it
was offered for the collections?

[Craig Berry]

@Beta is only used on portions of the API which are likely to change.
Much of the API, including nearly all of common.collect, is not
annotated with @Beta. So if you want to avoid using @Beta portions of
the API, just do that and you'll be fine.

I'm not sure what you mean by "no source package" -- can you clarify, please?

> --
> 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".
>

--
Craig Berry
Software Engineer
Google (Santa Monica CA)

[Kevin Bourrillion]

On Mon, Aug 2, 2010 at 11:27 PM, els <adrian....@gmail.com> wrote:

Is there an outlook for a released version of the guave project as it
was offered for the collections?

There have been four such released versions, called releases 03, 04, 05 and 06.  We're busily working on 07. :-)

Please be more specific about problems you're having.  Thanks.

--
Kevin Bourrillion @ Google
http://guava-libraries.googlecode.com

[els]

First of all. I think the guave project is a pretty good idea. At
least since the apache commons is not going forward.

Sorry about the statement about the src package. I had another project
in mind.

I've got following problems:
- I'm working in a company where I can't get libs as i like, I have to
ask one of the architecture team to add libs into the repo.
-We don't know what 03, 04, 05, and so on means. Is it a major
release? Is it just a minor?
-The @Beta annotation might be a good thing. But, in my opinion this
is nothing for a productive system. I know our developers, if they see
a method which is useful they WANT to use it. (Some may see the
annotation and let it be... but the others...)

Thanks for the good work in the guave project. :)

[Kevin Bourrillion]

On Wed, Aug 4, 2010 at 10:21 AM, els <adrian....@gmail.com> wrote:

I've got following problems:
- I'm working in a company where I can't get libs as i like, I have to
ask one of the architecture team to add libs into the repo.
-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.

-The @Beta annotation might be a good thing. But, in my opinion this
is nothing for a productive system. I know our developers, if they see
a method which is useful they WANT to use it. (Some may see the
annotation and let it be... but the others...)

The key consideration here is whether your code constitutes a library or framework that will in turn be used on the classpath of other users outside your control.  In that case, using @Beta APIs is ill-advised.

Most people, though, are developing applications.  You control your own classpath, end of story.  In this case, the dangers of a @Beta API are few.  If you use it, you might have to make some adjustments at a future date when you decide to upgrade Guava.  Is that so bad?  It's hard to imagine the pain of such adjustments actually being worse than not getting to use the library in the first place.  These libraries are there to be used.

-- 

[Johan Van den Neste]

> Most people, though, are developing applications.  You control your own
> classpath, end of story.  In this case, the dangers of a @Beta API are few.
>  If you use it, you might have to make some adjustments at a future date
> when you decide to upgrade Guava.  Is that so bad?  It's hard to imagine the
> pain of such adjustments actually being worse than not getting to use the
> library in the first place.  These libraries are there to be used.

I strongly second that.

--
Johan Van den Neste

[els]

I agree with you, such libraries are there to be used. But when do
they change? And what will be changed? Sure they should be changed
otherwise it is dead!

But I miss a version that tells me what could be changed. Are there
only bug fixes? Or might there be a method killed which was deprecated
or not stable?
Standard libs or tools should have a version that tells about the
impact of the change between one version and another.
If there is a version with two parts I know if the second number
increased there will nothing be changed on the public interface which
breaks my code. There are just bugfixes or new fuctionalities. But if
the first number is increased I know this can or breaks my code.
I agree with you, that it will be a mess if there is a version number
with more than two or three parts. Thats confusing.

--
Adrian Elsener

[Torbjorn Gannholm]

I usually use the compiler and the tests to find out if the code broke. That's much more likely to tell me the correct answer in a fairly effortless way.

For your peace of mind, just consider every release a major release for all things marked @Beta and a minor release for all things not marked @Beta.

If you need better control on your side, perhaps you can make an annotation processor?

/tobe

[Sam Berlin]

On Thu, Aug 5, 2010 at 1:44 AM, els <adrian....@gmail.com> wrote:

I agree with you, such libraries are there to be used. But when do
they change? And what will be changed? Sure they should be changed
otherwise it is dead!

But I miss a version that tells me what could be changed. Are there
only bug fixes? Or might there be a method killed which was deprecated
or not stable?

If you are using @Beta methods, every release has the (unlikely) potential of breaking some of your code.  If you are only using methods without @Beta, no release will ever break your code (though it might deprecate some methods).  Release notes typically will mention what, if anything, changed in @Beta methods.  As Kevin said, if you're a library that other developers use -- stay away from @Beta methods, whereas if you're writing your own application, use @Beta methods if you want and clean up the usage if there's any changes on new releases.

sam



 

Standard libs or tools should have a version that tells about the
impact of the change between one version and another.
If there is a version with two parts I know if the second number
increased there will nothing be changed on the public interface which
breaks my code. There are just bugfixes or new fuctionalities. But if
the first number is increased I know this can or breaks my code.
I agree with you, that it will be a mess if there is a version number
with more than two or three parts. Thats confusing.

--
Adrian Elsener

[Craig Berry]

On Wed, Aug 4, 2010 at 10:44 PM, els <adrian....@gmail.com> wrote:
> But I miss a version that tells me what could be changed. Are there
> only bug fixes? Or might there be a method killed which was deprecated
> or not stable?

That's precisely what the @Beta annotation is for. Anything labeled
with @Beta may change or disappear in any release. Obviously, we won't
do so lightly, but it's very possible we could rethink our approach
and change things around. However, we don't *expect* to do that.
Things that have gotten as far as being part of Guava are considered
to be in pretty good shape. @Beta is a mark of our conservatism; we're
not *sure* they're stable, so we provide a warning.

Anything not marked as @Beta can be considered to be as totally stable
as anything ever is in software. :)

[els]

Ok, might be this is a good idea. But I miss the support from our IDE
(eclipse) as it is with the @Deprecated anntoation.
If you don't have a look to the source you will not be able to see if
the method/class has this annotation.

I am not really happy with this smell of unknowing what method I
should use or not.

--
Adrian Elsener

[Johan Van den Neste]

Eclipse 3.6 now displays an element's annotations in the javadoc
tooltip. That helps. Although it is not as useful as, say, enabling a
compiler warning on @Beta annotations.

Alternatively, you could discuss it with the findbugs dev team. I
believe they are very open to these types of suggestions.

Johan Van den Neste

[Raymond Conner]

You're putting a lot of faith in the authors of those libraries. To my
knowledge, no one has ever officially defined what the X.Y.Z parts of
a version number mean. My corner of my employer has a rule that an
increment of the third number means it must be backwards compatible.
But that's just something we decided.

I've seen other projects that don't do that, for a number of reasons.
Government types follow the numbers blindly (as you seem to be doing),
and software doesn't have to be re-approved if only the third number
changes. That leads some software shops to only change the third
number no matter how different it is, because the pain of the approval
process is too great.

IMHO, @Beta is a much better solution. The API contract is in the
source code, not the version number.

- Ray A. Conner

On Thu, Aug 5, 2010 at 1:44 AM, els <adrian....@gmail.com> wrote:

[Blair Zajac]

On 08/09/2010 06:44 AM, Raymond Conner wrote:
> You're putting a lot of faith in the authors of those libraries. To my
> knowledge, no one has ever officially defined what the X.Y.Z parts of
> a version number mean. My corner of my employer has a rule that an
> increment of the third number means it must be backwards compatible.
> But that's just something we decided.

There's this document up for the C Apache Portable Runtime which is
pretty applicable to other non-C based projects with caveats for each
language:

http://apr.apache.org/versioning.html

Blair

[Colin Decker]

There's also Semantic Versioning: http://semver.org/

--