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.
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
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