Re: [DISCUSS] Branching and release: version numbers

[Julian Reschke]

On 30.09.2019 12:09, Marcel Reutegger wrote:

Hi,

In my view, using an odd numbered snapshot version would be better
as well. According to versionatorr, OSGi will consider 1.20-SNAPSHOT
more recent than 1.20.0.

http://versionatorr.appspot.com/?a=1.20-SNAPSHOT=1.20.0

Regards
  Marcel


OK, I'll put that onto the "creating releases" page, so we'll do it
right next time.

Changing this for the current trunk version (now 1.20-SNAPSHOT) would
probably just confusing.

Best regards, Julian

Re: [DISCUSS] Branching and release: version numbers

[Konrad Windszus]

Semantic Versioning mandates not only package version changes but also bundle 
version changes. Compare with 
https://www.osgi.org/developer/white-papers/semantic-versioning/bundles-and-fragments/
 


" The version of a bundle must therefore semantically aggregate the semantics 
of all its constituent packages. If any of these packages are incompatible with 
its providers then the bundle version must increment the minor version. If any 
of these packages are incompatible with consumers, the bundle version must 
increment the major version."

This is sometimes conflicting with odd/even versions: 
https://github.com/bndtools/bnd/issues/3446 


Konrad

> On 30. Sep 2019, at 12:09, Marcel Reutegger  
> wrote:
> 
> Hi,
> 
> In my view, using an odd numbered snapshot version would be better
> as well. According to versionatorr, OSGi will consider 1.20-SNAPSHOT
> more recent than 1.20.0.
> 
> http://versionatorr.appspot.com/?a=1.20-SNAPSHOT=1.20.0
> 
> Regards
> Marcel
> 
> On 27.09.19, 11:57, "Julian Reschke"  wrote:
> 
>On 04.03.2019 14:29, Davide Giannella wrote:
>> ...
> 
>Picking up an old thread...
> 
>So we've released 1.12.0, 1.14.0, 1.16.0, and will release 1.18.0 next 
> week.
> 
>What we apparently did not discuss what the project version for trunk
>should be in the meantime.
> 
>So far, we've been using 1.12-SNAPSHOT, etc, and we are on 1.20-SNAPHOT
>right now.
> 
>This however seems incorrect to me; shouldn't it be 1.19-SNAPSHOT?
> 
>For this release I'd like to avoid any changes, but for future releases
>I'd like to document that we're using an odd-numbered version.
> 
>Feedback appreciated,
> 
>Julian
> 
> 
> 

Re: [DISCUSS] Branching and release: version numbers

[Marcel Reutegger]

Hi,

In my view, using an odd numbered snapshot version would be better
as well. According to versionatorr, OSGi will consider 1.20-SNAPSHOT
more recent than 1.20.0.

http://versionatorr.appspot.com/?a=1.20-SNAPSHOT=1.20.0

Regards
 Marcel

On 27.09.19, 11:57, "Julian Reschke"  wrote:

On 04.03.2019 14:29, Davide Giannella wrote:
> ...

Picking up an old thread...

So we've released 1.12.0, 1.14.0, 1.16.0, and will release 1.18.0 next week.

What we apparently did not discuss what the project version for trunk
should be in the meantime.

So far, we've been using 1.12-SNAPSHOT, etc, and we are on 1.20-SNAPHOT
right now.

This however seems incorrect to me; shouldn't it be 1.19-SNAPSHOT?

For this release I'd like to avoid any changes, but for future releases
I'd like to document that we're using an odd-numbered version.

Feedback appreciated,

Julian

Re: [DISCUSS] Branching and release: version numbers

[Andrei Dulceanu]

+1

Regards,
Andrei

On Fri, Sep 27, 2019 at 4:22 PM Matt Ryan  wrote:

> +1.  I was wondering this same thing.
>
>
> =MR
>
> On Fri, Sep 27, 2019 at 3:57 AM Julian Reschke 
> wrote:
>
> > On 04.03.2019 14:29, Davide Giannella wrote:
> > > ...
> >
> > Picking up an old thread...
> >
> > So we've released 1.12.0, 1.14.0, 1.16.0, and will release 1.18.0 next
> > week.
> >
> > What we apparently did not discuss what the project version for trunk
> > should be in the meantime.
> >
> > So far, we've been using 1.12-SNAPSHOT, etc, and we are on 1.20-SNAPHOT
> > right now.
> >
> > This however seems incorrect to me; shouldn't it be 1.19-SNAPSHOT?
> >
> > For this release I'd like to avoid any changes, but for future releases
> > I'd like to document that we're using an odd-numbered version.
> >
> > Feedback appreciated,
> >
> > Julian
> >
> >
>

Re: [DISCUSS] Branching and release: version numbers

[Matt Ryan]

+1.  I was wondering this same thing.


=MR

On Fri, Sep 27, 2019 at 3:57 AM Julian Reschke 
wrote:

> On 04.03.2019 14:29, Davide Giannella wrote:
> > ...
>
> Picking up an old thread...
>
> So we've released 1.12.0, 1.14.0, 1.16.0, and will release 1.18.0 next
> week.
>
> What we apparently did not discuss what the project version for trunk
> should be in the meantime.
>
> So far, we've been using 1.12-SNAPSHOT, etc, and we are on 1.20-SNAPHOT
> right now.
>
> This however seems incorrect to me; shouldn't it be 1.19-SNAPSHOT?
>
> For this release I'd like to avoid any changes, but for future releases
> I'd like to document that we're using an odd-numbered version.
>
> Feedback appreciated,
>
> Julian
>
>

Re: [DISCUSS] Branching and release: version numbers

[Stefan Egli]

+1

Cheers,
Stefan

On 27.09.19 11:40, Julian Reschke wrote:

On 04.03.2019 14:29, Davide Giannella wrote:

...


Picking up an old thread...

So we've released 1.12.0, 1.14.0, 1.16.0, and will release 1.18.0 next 
week.


What we apparently did not discuss what the project version for trunk
should be in the meantime.

So far, we've been using 1.12-SNAPSHOT, etc, and we are on 1.20-SNAPHOT
right now.

This however seems incorrect to me; shouldn't it be 1.19-SNAPSHOT?

For this release I'd like to avoid any changes, but for future releases
I'd like to document that we're using an odd-numbered version.

Feedback appreciated,

Julian

Re: [DISCUSS] Branching and release: version numbers

[Julian Reschke]

On 04.03.2019 14:29, Davide Giannella wrote:

...


Picking up an old thread...

So we've released 1.12.0, 1.14.0, 1.16.0, and will release 1.18.0 next week.

What we apparently did not discuss what the project version for trunk
should be in the meantime.

So far, we've been using 1.12-SNAPSHOT, etc, and we are on 1.20-SNAPHOT
right now.

This however seems incorrect to me; shouldn't it be 1.19-SNAPSHOT?

For this release I'd like to avoid any changes, but for future releases
I'd like to document that we're using an odd-numbered version.

Feedback appreciated,

Julian

Re: [DISCUSS] Branching and release: version numbers

[Matt Ryan]

On Wed, Mar 20, 2019 at 4:53 AM Julian Reschke 
wrote:

> On 20.03.2019 11:36, Davide Giannella wrote:
> > On 05/03/2019 10:18, Davide Giannella wrote:
> >> On 04/03/2019 13:31, Robert Munteanu wrote:
> >>> As you mentioned, we don't need to increase the major version whenever
> >>> we branch. I just wanted to clarify that since in this email thread
> >>> branching seems to be conflated with major version increases and that
> >>> IMO not correct (and your reply seems to support that).
> >> +1
> >>
> >
> > during a chat with Amit a realised that we will still have to release a
> > version number with a revision to `0`.  So we'll have 1.12.0, 1.14.0,
> > 1.16.0 etc.
> >
> > This will make our life easier in OSGi environments when we'll have to
> > branch as the first patch release will be 1.14.1 (for example) which
> > will definitely be greater than 1.14.0.
> >
> > OSGi and maven speaking 1.14 and 1.14.0 are the same version
> >
> > http://versionatorr.appspot.com/?a=1.14=1.14.0
> >
> > so we either make sure to release 1.14 and 1.14.1 or we release 1.14.0.
> >
> > Thoughts?
>
> In the spirit of not changing things that do not need to be changed:
> 1.14.0.
>
>
>
+1

-MR

Re: [DISCUSS] Branching and release: version numbers

[Marcel Reutegger]

On 20.03.19, 12:00, "Julian Reschke"  wrote:
> In the spirit of not changing things that do not need to be changed: 1.14.0.

+1

Regards
 Marcel

Re: [DISCUSS] Branching and release: version numbers

[Julian Reschke]

On 20.03.2019 11:36, Davide Giannella wrote:

On 05/03/2019 10:18, Davide Giannella wrote:

On 04/03/2019 13:31, Robert Munteanu wrote:

As you mentioned, we don't need to increase the major version whenever
we branch. I just wanted to clarify that since in this email thread
branching seems to be conflated with major version increases and that
IMO not correct (and your reply seems to support that).

+1



during a chat with Amit a realised that we will still have to release a
version number with a revision to `0`.  So we'll have 1.12.0, 1.14.0,
1.16.0 etc.

This will make our life easier in OSGi environments when we'll have to
branch as the first patch release will be 1.14.1 (for example) which
will definitely be greater than 1.14.0.

OSGi and maven speaking 1.14 and 1.14.0 are the same version

http://versionatorr.appspot.com/?a=1.14=1.14.0

so we either make sure to release 1.14 and 1.14.1 or we release 1.14.0.

Thoughts?


In the spirit of not changing things that do not need to be changed: 1.14.0.

Best regards, Julian

Re: [DISCUSS] Branching and release: version numbers

[Davide Giannella]

On 05/03/2019 10:18, Davide Giannella wrote:
> On 04/03/2019 13:31, Robert Munteanu wrote:
>> As you mentioned, we don't need to increase the major version whenever
>> we branch. I just wanted to clarify that since in this email thread
>> branching seems to be conflated with major version increases and that
>> IMO not correct (and your reply seems to support that).
> +1
>

during a chat with Amit a realised that we will still have to release a
version number with a revision to `0`.  So we'll have 1.12.0, 1.14.0,
1.16.0 etc.

This will make our life easier in OSGi environments when we'll have to
branch as the first patch release will be 1.14.1 (for example) which
will definitely be greater than 1.14.0.

OSGi and maven speaking 1.14 and 1.14.0 are the same version

http://versionatorr.appspot.com/?a=1.14=1.14.0

so we either make sure to release 1.14 and 1.14.1 or we release 1.14.0.

Thoughts?

Davide

Re: [DISCUSS] Branching and release: version numbers

[Davide Giannella]

On 04/03/2019 13:31, Robert Munteanu wrote:
> As you mentioned, we don't need to increase the major version whenever
> we branch. I just wanted to clarify that since in this email thread
> branching seems to be conflated with major version increases and that
> IMO not correct (and your reply seems to support that).

+1

D.

Re: [DISCUSS] Branching and release: version numbers

[Robert Munteanu]

On Mon, 2019-03-04 at 13:24 +, Davide Giannella wrote:
> On 04/03/2019 12:08, Robert Munteanu wrote:
> > It all sounds reasonable to me. One comment regarding your example
> > -
> > branching does not necessarily force to increase the major
> > component of
> > the version.
> > 
> > > From your initial email, one use case for having maintenance
> > > branches
> > is to support incompatible changes in the JVM.
> > 
> > Asumming that with 1.26 we want to end Java 19 support, then the
> > next
> > Oak release could be 1.28, as we did not previously treat such
> > changes
> > as 'breaking'.
> 
> hmmm. We will add/change JVM even without branching if it will not
> require us to change API in a non-compatible way. By the definition I
> gave before a Major change is for:
> 
> > > MAJOR version when you make incompatible API changes.
> 
> so while in the past we didn't branch for JVM itself I think it
> happened
> either along with a new branch anyhow or it didn't require us to
> change
> our API in a non-compatible way.

I was referring to your previous email [1] which listed

- incompatible changes in the JVM which we may have or want to use

My understanding is that this would be something like "make use of new
API available only from Java 11".  And that was listed as a reason for
branching.

As you mentioned, we don't need to increase the major version whenever
we branch. I just wanted to clarify that since in this email thread
branching seems to be conflated with major version increases and that
IMO not correct (and your reply seems to support that).

Thanks,

Robert

[1]: 
https://lists.apache.org/thread.html/768807eed3379dc08921a1510264136ffe4a7a1230d9ca7881cc0a59@%3Coak-dev.jackrabbit.apache.org%3E

Re: [DISCUSS] Branching and release: version numbers

[Davide Giannella]

On 04/03/2019 12:43, Julian Reschke wrote:
> On 01.03.2019 10:48, Davide Giannella wrote:
>> Good morning everyone,
>>
>> it looks like the strategy proposed in a previous post about future
>> branching and strategies[0] is good with everyone. Now it's time to
>> discuss the version number schema we'd like to adopt.
>>
>> Referring to https://semver.org/ which goes along what I was taught in
>> school we could apply the following rules on version numbers
>>
>>   1. MAJOR version when you make incompatible API changes,
>>   2. MINOR version when you add functionality in a backwards-compatible
>>  manner, and
>>   3. PATCH version when you make backwards-compatible bug fixes.
>
> Hm - doesn't that introduce potential confusion with the package
> export versions, for which Semver is relevant only?

I think is more or less the same level of confusion we currently have.
One thing is the API/OSGi export versions and the other are the product
version. For example Oak 7.34 could introduce an API change but only for
a specific package while leaving untouched the rest of the code base.
For us it will be a non-compatible change and forcing us to branch but
to a keen eye it may be a compatible change as the product using Oak is
not using that specific package.

By keeping the two concept separated will help, IMO, to instruct tools
in what is actually compatible for a specific product.

> I'm not sure how to read this? Is your proposal to start with 2.0 as
> first stable release?

No. The first stable will be 1.12, followed (hopefully) by 1.14.

D.

Re: [DISCUSS] Branching and release: version numbers

[Davide Giannella]

On 04/03/2019 12:08, Robert Munteanu wrote:
> It all sounds reasonable to me. One comment regarding your example -
> branching does not necessarily force to increase the major component of
> the version.
>
> >From your initial email, one use case for having maintenance branches
> is to support incompatible changes in the JVM.
>
> Asumming that with 1.26 we want to end Java 19 support, then the next
> Oak release could be 1.28, as we did not previously treat such changes
> as 'breaking'.

hmmm. We will add/change JVM even without branching if it will not
require us to change API in a non-compatible way. By the definition I
gave before a Major change is for:

>> MAJOR version when you make incompatible API changes.

so while in the past we didn't branch for JVM itself I think it happened
either along with a new branch anyhow or it didn't require us to change
our API in a non-compatible way.

D.

Re: [DISCUSS] Branching and release: version numbers

[Julian Reschke]

On 01.03.2019 10:48, Davide Giannella wrote:

Good morning everyone,

it looks like the strategy proposed in a previous post about future
branching and strategies[0] is good with everyone. Now it's time to
discuss the version number schema we'd like to adopt.

Referring to https://semver.org/ which goes along what I was taught in
school we could apply the following rules on version numbers

  1. MAJOR version when you make incompatible API changes,
  2. MINOR version when you add functionality in a backwards-compatible
 manner, and
  3. PATCH version when you make backwards-compatible bug fixes.


Hm - doesn't that introduce potential confusion with the package export 
versions, for which Semver is relevant only?



Given that any new release will always include both bugs and features,
point 3 does not really apply to us. We're therefore left with a schema
of MAJOR.MINOR.

Additionally, even if not strictly required I would keep the even/odd
schema we currently have. With the exception that we won't ever release


Yes.


odd versions as by definition we account any release as stable.

All given we have the following examples:

1.12, 1.14, 1.16, 1.18, 1.20, ..., 1.26

Now let's say we have to branch at 1.26 time we would create a branch
`svn/.../branches/1.26` that will produce thereafter 1.26.0, 1.26.1, etc.

Trunk will become: 2.0, 2.2, 2.4, 2.6, etc.

Thoughts?
Davide


I'm not sure how to read this? Is your proposal to start with 2.0 as 
first stable release?


Best regards, Julian

Re: [DISCUSS] Branching and release: version numbers

[Robert Munteanu]

Hi Davide,

On Fri, 2019-03-01 at 09:48 +, Davide Giannella wrote:
> Now let's say we have to branch at 1.26 time we would create a branch
> `svn/.../branches/1.26` that will produce thereafter 1.26.0, 1.26.1,
> etc.
> 
> Trunk will become: 2.0, 2.2, 2.4, 2.6, etc.

It all sounds reasonable to me. One comment regarding your example -
branching does not necessarily force to increase the major component of
the version.

>From your initial email, one use case for having maintenance branches
is to support incompatible changes in the JVM.

Asumming that with 1.26 we want to end Java 19 support, then the next
Oak release could be 1.28, as we did not previously treat such changes
as 'breaking'.

Thanks,

Robert

[DISCUSS] Branching and release: version numbers

[Davide Giannella]

Good morning everyone,

it looks like the strategy proposed in a previous post about future
branching and strategies[0] is good with everyone. Now it's time to
discuss the version number schema we'd like to adopt.

Referring to https://semver.org/ which goes along what I was taught in
school we could apply the following rules on version numbers

 1. MAJOR version when you make incompatible API changes,
 2. MINOR version when you add functionality in a backwards-compatible
manner, and
 3. PATCH version when you make backwards-compatible bug fixes.


Given that any new release will always include both bugs and features,
point 3 does not really apply to us. We're therefore left with a schema
of MAJOR.MINOR.

Additionally, even if not strictly required I would keep the even/odd
schema we currently have. With the exception that we won't ever release
odd versions as by definition we account any release as stable.

All given we have the following examples:

1.12, 1.14, 1.16, 1.18, 1.20, ..., 1.26

Now let's say we have to branch at 1.26 time we would create a branch
`svn/.../branches/1.26` that will produce thereafter 1.26.0, 1.26.1, etc.

Trunk will become: 2.0, 2.2, 2.4, 2.6, etc.

Thoughts?
Davide


0)
https://lists.apache.org/thread.html/768807eed3379dc08921a1510264136ffe4a7a1230d9ca7881cc0a59@%3Coak-dev.jackrabbit.apache.org%3E