Tatu,
> Yes, when you know meaning of versions. But no, since you can not
> forecast in advance what the semantics are (not even necessarily for
> packages you own, much less for packages others own).
> Major version bump could be something that renders new version
> incompatible.
This is not true. The sense of a version schema is to provide the
availability of forecasts. If one follows the Maven 2 best practices, then
any API change will result in either major or minor change, while all bug
fixes will not advance major nor minor but only bugfix or build parts. So
this IS predictable.
Even when not following Maven's best practices, virtually every organization
will have clear directives what kind of change will result in what kind of
version change. In our company for example, each file has a.b.c.d version
number, where a++ means "complete reprogramming", b++ means "added or
removed feature", c++ means "bug fixed, but stable API", d++ means "another
compiler run inside of a.b.c". That is made clear to all users so they can
100% rely that any a.b.*.* is absolutely compatible with any other a.b.*.*.
If a company or project does not have such strict rules, you will soon end
up with the total chaos at support & consulting.
The proposed version range above follows Maven's best practice and would
guarantee that you will have the same API with before, but any bugs getting
fixed, without the need to look for updates.
So what do you fear? Getting a bug fixed that you liked to keep? ;-)
> You only know once definition of release is available, after release
> is done, or shortly before it is being made. You can of course have
> plans on kinds of compatibility levels you try to achieve, but they
> are just plans, and most OS projects would choose "right thing" over
> "previously planned", breaking compatibility whenever it is deemed the
> right thing to do.
Well, I wonder in what company you are working. Our customers would kill us
if we do not strictly follow the version numbering rules, since all of them
do rely heavily on that... It's not about planning vs. actual doing. It's
about following a schema vs. having chaos. You can break compatibility
whenever you want -- but you must name the version in the right way, still.
Since the past 25 years this works perfectly four our 120.000 users
worldwide. Compatibility is neither a burden not done by chance. It is a
feature, and it is getting planned. Everything else is not agile, but chaos.
Do you really want to break API compatibility when doing just a
"*.*.*.d++"-Release? Oh my god, then I won't be your customer... ;-)
> It would work if one did know what future major versions mean. I just
> don't think this happens often.
Just ask the project leads and they will tell you. At least for virtually
all of the open source projects and commercial products I am producing and
consuming. Never saw an API change in a *.*.c++ or *.*.*.d++ release,
actually.
> It also depends on how conservative one wants to be: one potential
> view is that you just specify minimum version you need, and hope
> future versions are backwards compatible.
Again, this is not about hope, it is about agreements and contracts with the
project leads.
> And/or that by time actual
> incompatibilities arise, your package has evolved much further and you
> have had time to clarify dependencies. This can work if your package
> is actively evolving, and your users are quick to upgrade to newer
> versions.
Sorry to hear that. If this is the world you live in then I wonder where I
lived the past 25 years. Never experienced that problem, actually.
>
> -+ Tatu +-
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net