As always, thanks guys, for sharing your thoughts! :-)
> It's essentially a lose-lose choice.
Well, people still win. They could've developed (and maintained)
something like jOOQ themselves, which would have been much more
expensive. The occasional bug / funny feature is usually acceptable
just as much as the occasional backwards-incompatibility of API or of
behaviour. I tend to see the glass half-full, when I get something for
free, as long as I'm made aware of these things through user groups,
release notes, etc.
> Again, only MS can get away with that ;-)
Actually, I find MS pretty impressive. You can probably still run
dinosaur Win95 programs on Windows 8. Try that with Apple's
products...
And there are others. Take PHP, for instance. The most impactful
backwards-compatibility that I have ever seen. Consider this piece of
code:
-----------------------------------------------
$joe = new Person();
$joe->sex = 'male';
$betty = $joe;
$betty->sex = 'female';
echo $joe->sex;
-----------------------------------------------
Output in PHP4: 'female' // $betty = $joe copies by value
Output in PHP5: 'male' // $betty = $joe copies by reference
Try to maintain any sensible data structure compatibly between PHP4
and 5... Still, they got away with it, somehow.
Other examples:
- HSQLDB 1.x -> 2.x (from proprietary to SQL standard)
- JDom 1.x -> 2.x
- JDBC x.x -> y.y (without Java 8's extension methods, API evolution
is hard in Java)
- Scala (lots of language experimentation there). Actually, with
implicit defs, I'm not sure if anything can be developed
backwards-compatibly in Scala
- jOOQ 2.x -> 3.x (e.g. some inevitable changes due to making typed
row value expressions first-class citizens)
> The Linux people have found a very interesting tactics: They make
> a clear distinction whether you're "inside" or "outside" (my
> terminology).
Yes, I try to do the same. You can never rely on jOOQ's internals.
That's why they're package-private within org.jooq.impl, or documented
in the Javadoc ("internal to jOOQ, do not use").
> For Jooq, the easiest way would probably be adding annotations
> on classes, members, and test cases - could be named @Eternal or
> something.
> Something annotated @Eternal would be there to stay, even in Jooq
> 42.0. Something without that annotation might get deprecated, or
> have slight semantic changes.
You wish :-)
1. It would take me forever to carefully assess the applicability of
this annotation for every class/member
2. I find @Internal a much more interesting and reliable information.
With @Internal, you can be sure that it's a bad idea to use this. (I
might actually do that! This is #2026:
https://github.com/jOOQ/jOOQ/issues/2026).
3. From my jOOQ experience, I've had so many bad and incomplete ideas
implemented and thrown out again, I wouldn't dare put the @Eternal
annotation anywhere.
> Of course, it would be hard to determine what could be annotated
> that way. It should be the kind of commitment that programmers
> can bet serious money on.
Well, if I get a cash advance on those bets, we can start discussing :-)
I think jOOQ should follow the semantic versioning rules explained in
http://semver.org, which was suggested by Vladislav Rastrusny on this
user group, here in early 2012:
https://groups.google.com/d/topic/jooq-user/3wyTXLwX9Sw/discussion
I have slightly adapted the rules of semver to my own use, as full
backwards-compatibility between minor releases in a DSL like jOOQ
cannot be achieved, as I need to frequently add methods to interfaces,
which aren't supposed to be implemented by client code anyway.
Probably, there should be a chapter in the manual: "Semantic
Versioning as understood by jOOQ": Let's register this as #2027:
https://github.com/jOOQ/jOOQ/issues/2027
Cheers
Lukas
