| Re: [birt-dev] Creating a new release |
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,
AF06.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 listbirt-dev@xxxxxxxxxxxTo 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 RosenbaumInnovent 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