Semantic versioning for JOOQ?

[FractalizeR]

Hi!

Haven't you considered using something like semantic versioning for JOOQ libraries? It's quite unusual to see 2.0.4 and 2.0.5 versions bursting with new features while 2.0.2 only introduced some improvements...

[Lukas Eder]

Hello Vladislav

> Haven't you considered using something like semantic versioning for JOOQ
> libraries? It's quite unusual to see 2.0.4 and 2.0.5 versions bursting with
> new features while 2.0.2 only introduced some improvements...

You mean, like Firefox quickly jumping from 3.6.2 to 10 without many
fundamental improvements? ;-)

On a more serious note, I have considered doing that. But my roadmap
has no planning (nor branching, the interest for 1.7.x seems pretty
slim), and my release cycles are short. It's hard to say in advance,
whether the next release is a patch release or a minor one. For
instance:

2.0.4: Minor release or patch? I introduced a lot of new jooq-codegen
features, but jOOQ itself only had trivial improvements
2.0.5: Runtime configuration was added and a new Maven module. But
most of jOOQ stays the same

How to decide? I don't know. So I'm just incrementing the last two
digits (after 2.0.9 will come 2.1.0). On the other hand, maybe I
should drop the last digit and publish 2.09, 2.10, 2.11, etc?

I'm open to more concrete suggestions. E.g. how would you have
versioned the last 10-15 versions and why?

Cheers
Lukas

[FractalizeR]

Well, patch is a patch ;) It's just a correction for bugs. And I think a release should not contain both bugfixes and new features. Either one or another, not both together. If you use some good version control software, that shouldn't be a problem.

I would prefer to see third version number digit changed if only bugfixes are introduced and I need to upgrade my project to use new Jooq version.

I would prefer to see second version number digit changed if some new functionality was added while all public API remained unchanged or fully compatible with old one. In this case I will decide if I want to upgrade or not since introducing new features sometimes introduces some bugs also. May be I have a project, that needs to stay super-stable and I fear updates and new features like hell's fire.

I would prefer to see first version digit changed if public API has changed so that I can no longer build/run my project with new jooq version and I need to adapt my code to use it.

http://semver.org/




вторник, 28 февраля 2012 г. 18:24:20 UTC+4 пользователь Lukas Eder написал:

вторник, 28 февраля 2012 г. 18:24:20 UTC+4 пользователь Lukas Eder написал:

вторник, 28 февраля 2012 г. 18:24:20 UTC+4 пользователь Lukas Eder написал:

[Lukas Eder]

Hello Vladislav,

> Well, patch is a patch ;) It's just a correction for bugs. And I think a
> release should not contain both bugfixes and new features. Either one or
> another, not both together. If you use some good version control software,
> that shouldn't be a problem.

The problem is not the version control system (SVN or Git). The
problem is time. Maintaining several branches at the same time can be
tedious, especially when SVN is as slow as that of sourceforge, but
that's another story. Maybe that'll be a reason to finally abandon SVN
and only use Git/GitHub

> I would prefer to see third version number digit changed if only bugfixes
> are introduced and I need to upgrade my project to use new Jooq version.
>
> I would prefer to see second version number digit changed if some new

> functionality was added [...]

>
> I would prefer to see first version digit changed if public API has changed

> [...]

I agree with that, in general, and I like your link. I'm trying to
follow the first digit policy as much as possible. jOOQ's other two
digits might be a bit funky though. I should try maintaining branches
for a while, measuring the true demand for branching by checking
download statistics. So next release will be 2.1.0 and 2.0.6 for
bugfixes off 2.0.5

Do you have a similar resource that describes optimal iteration
planning? I like to release early and often, having new features
confirmed by many users. Currently, I'm releasing what you would call
a "minor release" (new features) every 2-3 weeks (this would probably
become 3-4 weeks with branching). How about patch releases? With so
many minor releases, I'd start new branches every 2-3 / 3-4 weeks too.
Are there best practices? i.e. I wouldn't merge trivial bugfixes to
branches. How often would branched patch releases be delivered?

Thanks for your input
Cheers
Lukas

PS: Anyone else following this (including Vladislav! :), if you feel
like becoming a branch master for jOOQ, your help would be greatly
appreciated!