Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [birt-dev] Creating a new release
The Eclipse Foundation has no opinion regarding how a project opts to name its versions beyond an expectation that the project team will avoid doing things that confuse users and adopters. Confusing the EMO is also strongly discouraged.

FWIW, "2021-03" is the name of the simultaneous release. The name of the simultaneous release is intentionally designed (for better or for worse) to be disconnected from any particular project release naming/numbering scheme. Projects that participate in the simultaneous release decide which of their own versions they will contribute.

Wayne

On Mon, Mar 8, 2021 at 12:56 PM <john@xxxxxxxxxxxx> wrote:

The last actual release was 4.8. A few forks (including mine) built a 4.11 or 4.12. 

-John


 

On 2021-03-08 11:36, Scott Rosenbaum wrote:

At a minimum, we need to jump beyond the old code to recognize we have moved beyond that. There is evidence that there was a 4.11 in the works, so I think our minimum is 4.12.
 
But at the end of the day, I am not the one doing the work right now, so I am happy to defer to those of you putting the time in.
 
Scott

On Mon, Mar 8, 2021 at 11:24 AM Alexander Lehmann <a.lehm@xxxxxx> wrote:
Open minded in the sense that you can choose to not use semantic versioning or to make a version jump and continue with semantic versioning thereafter 😉. If you chose to use it, then there are rules you have to follow. If the Eclipse Foundation has a policy that we must use it, then be it so.
 
Yes, maybe eclipse was not a good example, but here's another one: Java itself switched from semantic versioning (1.8) to something more handy (Java 11). The problem with semantic versioning is: when you do not intend to break your API at all, it soon gets annoying.
 
If we make the commitment to semantic versioning (the majority seems to stand behind this). Then I'd say after the next release (4.10.0) must follow 4.11.0.
 
Best regards
Alex

Wim Jongman <wim.jongman@xxxxxxxxx> schrieb am Mo., 8. März 2021, 18:04:
I don't think that semantic versioning is something that people can have different opinions about or more open-minded about it :)
 
 
> because in the past (being in sync with the platforms version) already was a violation of semantic versioning imho.
I don't think so. The minor version increment is API addition and such.

> Also what exactly is a breaking change and in which API? Some might regard the raising of the required Java version to Java 11 already a 'breaking change' (the bytecode of the API becomes incompatible). Also I see that semantic versioning is viewed critically in parts of the industry 
API breakage is well defined:
 
> and many move away from it
I don't think this is correct. If you provide API then the semantic version number is very important.
 
> (just look at Eclipse itself, '2021-03' is no semantic versioning).
Eclipse 2021-03 is the release name. 4.19 is the version number.
 
Cheers,
 
Wim
 
 
 
Let's give the release
 
Cheers,
 
Wim
 

On Mon, Mar 8, 2021 at 4:52 PM Alexander Lehmann <a.lehm@xxxxxx> wrote:
My suggestion is to create a new release with minimal changes incrementing minor version segment.
 
+1
I'd say we stick to this for the next release and thereafter discuss the version number of the release after that. Since there already was some kind of 4.9.0 somewhere (I have no idea), this would mean the next version should be 4.10.0.
 
I see two groups with different opinions in this thread: For the first one it seems to be important to stick to "semantic versioning" whilst the second one is more open minded towards the versioning scheme to be used. I personally tend more to the second one, because in the past (being in sync with the platforms version) already was a violation of semantic versioning imho. Also what exactly is a breaking change and in which API? Some might regard the raising of the required Java version to Java 11 already a 'breaking change' (the bytecode of the API becomes incompatible). Also I see that semantic versioning is viewed critically in parts of the industry and many move away from it (just look at Eclipse itself, '2021-03' is no semantic versioning).
 
Just my 2ct
Alex

Alexander Fedorov <alexander.fedorov@xxxxxxxxxx> schrieb am Mo., 8. März 2021, 15:21:
I'm not sure what is the latest officially released version.
My suggestion is to create a new release with minimal changes incrementing minor version segment.

Regards,
AF

08.03.2021 17:13, Scott Rosenbaum пишет:
Isn't there already a version 4.9.0 out there?
 
How do you differentiate the new 4.9.0 from the old one?
 
Scott

On Sun, Mar 7, 2021 at 5:23 AM Wim Jongman <wim.jongman@xxxxxxxxx> wrote:
I vote for prudence. It is tempting to use the version number as a marketing instrument but it may lead to confusion and false expectations.
 
As Christoper points out, going to V5 implies API breakage. This will cause disturbances with people having set the OSGi version range to [4.x.x, 5.0.0) (everything below version 5).
This should be avoided.
 
Skipping versions to artificially keep up with the Platform cycle will also cause confusion. Although as Wayne points out, it is technically possible, it is not something that anyone does and I wonder if we should deviate from common practice.
 
I'm with Alexander to first stabilize on version 4.9.
 
Cheers,
 
Wim
 
 
 

On Sun, Mar 7, 2021 at 10:19 AM Loetz, Christophe <ChLoetz@xxxxxxxxxxxxxxxxxxx> wrote:

Hi to everybody,

 

I follow closely the discussion which I find important. I think that first a definition of version, release, patch is needed:

 

o   Version = major technical and/or architectural changes (API may be incompatible from one version to the next).

 

o   Release = major functional enhancements (API remain compatible from one release to the next).

 

o   Patch = bug fixes (API remain compatible from one patch to the next)

 

 

Glossar:

Major Release or Major Version corresponds to the definition of Version

Minor Release or Minor Version corresponds to the definition of Release

 

Initial step to revitalize the BIRT project: 4.9.X -> 5.0.0 (Version.Release.Patch).

 

In addition to the technical implications, the user perspective on version nomenclature should be considered.

 

From a user perspective, using Birt in the context of the OSBP project, i.e. in an ERP environment, it is important that the release cycles, adapts to the inertia of an ERP environment. OSBP integrates over 27 projects and cannot continue a release every 3 months. We have about 150 customers with about 50,000 users who use our software and ergo Birt. Our users want release cycles to be 18 to 24 months. Version changes are to be avoided, as they generally cause a lot of work due to API incompatibilities.

 

WE know that many other users feel the same way.

 

Two messages must therefore cohabit in the versioning: Birt is actively developed and further developments are compatible as far as possible.

 

I hope that my non-technical remark is helpful

 

Regards

Chris

 

 

 

Von: birt-dev [mailto:birt-dev-bounces@xxxxxxxxxxx] Im Auftrag von Alexander Lehmann
Gesendet: Sonntag, 7. März 2021 09:21
An: For developers on the BIRT project
Betreff: Re: [birt-dev] Creating a new release

 

+1 for Alex' idea. The step to 5.0 would be the "we're back"-statement and it would circumvent the whole "in sync with platform versions or not" discussion.

Alexander Fedorov <alexander.fedorov@xxxxxxxxxx> schrieb am So., 7. März 2021, 08:46:

What target platform do we plan for the nearest release (SimRel version/Java version)?
Do we plan to increment major version segment after switching to Java 11 (that will happen one way or another after upgrading target to be >= 2020-09)?

I would create release 4.9.0 first on the current target with minimal changes (SimRel 2019-03/Java8) , to have stable zero point.
And then I would create 5.0.0 with SimRel 2021-06/Java11. After this bold attempt it will become more clear how often we are able to release.

Regards,
AF

06.03.2021 21:41, Wayne Beaton пишет:

There's no rule that says version numbers need to be in strict sequence.

 

We could number the first reboot release as 4.20 and then follow up with 4.23 nine months later (for example). A statement on the download page that indicates that release numbers are aligned with the Eclipse Platform release numbers (or something to that effect) should alleviate any "where is version XX?" type questions.

 

Aligning the release number with the platform may be perceived as a bold "we're back" statement. Other than that, however, I have no strong opinion on the matter.

 

Wayne

 

On Sat, Mar 6, 2021 at 1:27 PM Wim Jongman <wim.jongman@xxxxxxxxx> wrote:

This implies that we have to release every three months. I'm afraid that releasing 4x yearly might be too ambitious.

 

Cheers,

 

Wim

_______________________________________________
birt-dev mailing list
birt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/birt-dev

 

 

--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation

 

_______________________________________________
birt-dev mailing list
birt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/birt-dev

 

_______________________________________________
birt-dev mailing list
birt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/birt-dev

_______________________________________________
birt-dev mailing list
birt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/birt-dev
_______________________________________________
birt-dev mailing list
birt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/birt-dev

 
--
Scott Rosenbaum
Innovent Solutions, Inc.
612 220 6006 cell

_______________________________________________
birt-dev mailing list
birt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/birt-dev
_______________________________________________
birt-dev mailing list
birt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/birt-dev
_______________________________________________
birt-dev mailing list
birt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/birt-dev
_______________________________________________
birt-dev mailing list
birt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/birt-dev
_______________________________________________
birt-dev mailing list
birt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/birt-dev

 
--
Scott Rosenbaum
Innovent Solutions, Inc.
612 220 6006 cell

_______________________________________________
birt-dev mailing list
birt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/birt-dev
_______________________________________________
birt-dev mailing list
birt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/birt-dev


--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation

Back to the top