You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Georg Kallidis <ge...@cedis.fu-berlin.de> on 2023/02/17 14:33:05 UTC
Re: Planning the Release and Building of Turbine Core v5.2 Component and Required Fulcrum / Parent Components / Update / Questions
Hi all again,
although a RC of Turbine would currently contain some more changes, I am
not sure enough, what to do next.
1) I might be wrong. Reading about JDK 20^1 as the upcoming Java release
(current in release candidate status) I would almost strongly suggest to
proceed to this release rather than just set jdk 11 as lowest supported
level considering, that
- Turbine's active community is quite small scale now, we are not able to
release one major release more than once in a year or two.
- To set the lower level to a recent Java version might be restrictive
using incompatible source code with a Java 20-binary that could not be
executed in any previous Java environments.
- On the other side, the current Turbine 5.1 release is expected to work
at least until JDK 20 (TODO test it! I did some checks in JDK 17).
- If we want to use all the new features, and we are not able to support
multiple branches we just have to set the higher level, why not the
newest?
(I am remembering that Jeffery already voted for the newest version last
year.)
- Java 20 has some substantial changes and seems to me closing up some
long awaited changes (Project loom e.g.) and I personally hope, that this
will be a good level to keep for a couple of Java releases as the bottom
line (may be I am too confident here).
- We would thereby actively support (suggest/recommend) upgrading to Java
20 level using Turbine (we might even consider to take part in Outreach
programm https://wiki.openjdk.org/display/quality/Quality+Outreach later).
As a caveat, more work has to be done then, and a release might be ready
only at the end of the year.
2) At the moment at least 5 Fulcrum components need to be released, but
change is not very substantial. Nevertheless each of them requires a
release + voting process. The effort for those small changes seems to me -
quite extensive. And it seems to me, that there is a way to do a bundled
release. We didn't do this before, but
https://gitbox.apache.org/repos/asf/turbine-fulcrum-build.git
is a pom module (group-id: org.apache.turbine, articaft-id: fulcrum)
containing all currently Fulcrums in development. Might we decide to set
it up as a releaseable component?
Currently version is 1, but if we set version e.g. to 5 or 5.2-SNAPSHOT it
would be aligned to the Turbine version and high enou, as of course all
Fulcrum modules have to share the version, currently in the range of 1.0.5
and 2.2 (to be checked). We have at the moment 15 Fulcrum components (with
JSON and security modules 3 or 4 more), some very small (the size of a
binary is between 15kb and the biggest Security Torque has without javadoc
573kb. Turbine uses about 16 Fulcrum components and if we have a release
of a bulk Fulcrum component the size would not change very much.
3) Should we also support SBOM generation (e.g. with
cyclonedx-maven-plugin like Apache Commons or spdx)? This would go to the
parent module and we might think about updating the version from
12-SNAPSHOT to 13-SNAPSHOT or even 20-SNAPSHOT..
4) How should we decide? If there are no divergent views at the end of the
discussion, we might just hopefully proceed in consent. Nevertheless we
could do a vote ..
I'll be waiting for your opinion!
With best regards,
Georg
^1 You might've read this as well:
https://lists.apache.org/thread/l405tg3fnv0md3hxplv57hq665znbq8z
Von: "Georg Kallidis" <ge...@cedis.fu-berlin.de>
An: Turbine <de...@turbine.apache.org>
Datum: 10.01.2023 11:59
Betreff: Planning the Release and Building of Turbine Core v5.2
Component and Required Fulcrum / Parent Components
Hi all,
happy New Year!
I think, it's time to prepare a Turbine Core release 5.2.
There is some experimental stuff in it, notabely DateTimeFormatterService,
but a couple of tests exist and it seems to be ready to a certain degree.
Nevertheless Turbine Core does currently depend on five Fulcrum components
in state SNAPSHOT (testcontainer, intake, parser, security, yaafi) +
parent pom in SNAPSHOT.
We would have to first release the parent component v12-SNAPSHOT, if we
want to update the minimal setting to Java 11 or revert the settings to
the published version 11 in the new releases.
Overview of Fulcrum dependencies in Turbine 5.2-SNAPSHOT:
| name | version | last release | changes (commit for git diff) | remarks
|
| testcontainer | 1.0.10-SNAPSHOT | end of 2020 |
7d2f264371ec9d62d885212f1ef18c8b228bf650 | mostly cleanup and dependency
updates
| intake | 2.0.1-SNAPSHOT | beginning of 2019 |
44f7d9492d98c4e95d06a3da3380f7bf892bc26c | more complete test
configuration
| parser | 2.0.2-SNAPSHOT | end of 2019 |
4df41f39b79827927256343f2652b078f6bb04f4 | mostly cleanup and dependency
updates
| security | 2.1.1-SNAPSHOT | end of 2021 |
cacbef75a874c4ab489ed76489a1235b885b5f97 | some Java 8/11 optimizations
TODO Should we remove hibernate, as we are not able to follow security
updates and update hibernate to a current version? |
| yaafi | 1.0.9-SNAPSHOT | end of 2018 |
a931f52fbfca71c0a4a0f72ce8bc82e1ead80065 | mostly cleanup of tests and
dependency updates
What's your opinion? Do you agree? Did I miss something ?
Should we wait and integrate / work on some important stuff? Should we
just skip some Fulcrum updates? That is e.g. revert some dependencies in
Turbine Core v5.2-SNAPSHOT (e.g. if we do not want the Java 11 baseline
now in the new releases, we do not need parent 12)?
Should we proceed and start with the release bundles as set out (that is
as release first parent, then Fulcrum components and last Turbine-Core) ?
Thanks!
Best regards,
Georg
Re: Planning the Release and Building of Turbine Core v5.2 Component and Required Fulcrum / Parent Components / Update / Questions
Posted by Jeffery Painter <je...@jivecast.com>.
Hi Georg,
Sorry - work/life and I am back in school (again) doing a master's
degree (finally in CompSci!), so my time has been pretty limited. If
there is anything specific I can help with, please let me know and will
try to find some time in the coming weeks.
-
Jeff
On 2/17/23 09:33, Georg Kallidis wrote:
> Hi all again,
>
> although a RC of Turbine would currently contain some more changes, I am
> not sure enough, what to do next.
>
> 1) I might be wrong. Reading about JDK 20^1 as the upcoming Java release
> (current in release candidate status) I would almost strongly suggest to
> proceed to this release rather than just set jdk 11 as lowest supported
> level considering, that
>
> - Turbine's active community is quite small scale now, we are not able to
> release one major release more than once in a year or two.
> - To set the lower level to a recent Java version might be restrictive
> using incompatible source code with a Java 20-binary that could not be
> executed in any previous Java environments.
> - On the other side, the current Turbine 5.1 release is expected to work
> at least until JDK 20 (TODO test it! I did some checks in JDK 17).
> - If we want to use all the new features, and we are not able to support
> multiple branches we just have to set the higher level, why not the
> newest?
> (I am remembering that Jeffery already voted for the newest version last
> year.)
> - Java 20 has some substantial changes and seems to me closing up some
> long awaited changes (Project loom e.g.) and I personally hope, that this
> will be a good level to keep for a couple of Java releases as the bottom
> line (may be I am too confident here).
> - We would thereby actively support (suggest/recommend) upgrading to Java
> 20 level using Turbine (we might even consider to take part in Outreach
> programm https://wiki.openjdk.org/display/quality/Quality+Outreach later).
>
> As a caveat, more work has to be done then, and a release might be ready
> only at the end of the year.
>
> 2) At the moment at least 5 Fulcrum components need to be released, but
> change is not very substantial. Nevertheless each of them requires a
> release + voting process. The effort for those small changes seems to me -
> quite extensive. And it seems to me, that there is a way to do a bundled
> release. We didn't do this before, but
> https://gitbox.apache.org/repos/asf/turbine-fulcrum-build.git
> is a pom module (group-id: org.apache.turbine, articaft-id: fulcrum)
> containing all currently Fulcrums in development. Might we decide to set
> it up as a releaseable component?
>
> Currently version is 1, but if we set version e.g. to 5 or 5.2-SNAPSHOT it
> would be aligned to the Turbine version and high enou, as of course all
> Fulcrum modules have to share the version, currently in the range of 1.0.5
> and 2.2 (to be checked). We have at the moment 15 Fulcrum components (with
> JSON and security modules 3 or 4 more), some very small (the size of a
> binary is between 15kb and the biggest Security Torque has without javadoc
> 573kb. Turbine uses about 16 Fulcrum components and if we have a release
> of a bulk Fulcrum component the size would not change very much.
>
> 3) Should we also support SBOM generation (e.g. with
> cyclonedx-maven-plugin like Apache Commons or spdx)? This would go to the
> parent module and we might think about updating the version from
> 12-SNAPSHOT to 13-SNAPSHOT or even 20-SNAPSHOT..
>
> 4) How should we decide? If there are no divergent views at the end of the
> discussion, we might just hopefully proceed in consent. Nevertheless we
> could do a vote ..
>
> I'll be waiting for your opinion!
>
>
> With best regards,
> Georg
>
> ^1 You might've read this as well:
> https://lists.apache.org/thread/l405tg3fnv0md3hxplv57hq665znbq8z
>
>
>
> Von: "Georg Kallidis" <ge...@cedis.fu-berlin.de>
> An: Turbine <de...@turbine.apache.org>
> Datum: 10.01.2023 11:59
> Betreff: Planning the Release and Building of Turbine Core v5.2
> Component and Required Fulcrum / Parent Components
>
>
>
> Hi all,
>
> happy New Year!
>
> I think, it's time to prepare a Turbine Core release 5.2.
>
> There is some experimental stuff in it, notabely DateTimeFormatterService,
>
> but a couple of tests exist and it seems to be ready to a certain degree.
> Nevertheless Turbine Core does currently depend on five Fulcrum components
>
> in state SNAPSHOT (testcontainer, intake, parser, security, yaafi) +
> parent pom in SNAPSHOT.
> We would have to first release the parent component v12-SNAPSHOT, if we
> want to update the minimal setting to Java 11 or revert the settings to
> the published version 11 in the new releases.
>
> Overview of Fulcrum dependencies in Turbine 5.2-SNAPSHOT:
>
> | name | version | last release | changes (commit for git diff) | remarks
> |
> | testcontainer | 1.0.10-SNAPSHOT | end of 2020 |
> 7d2f264371ec9d62d885212f1ef18c8b228bf650 | mostly cleanup and dependency
> updates
> | intake | 2.0.1-SNAPSHOT | beginning of 2019 |
> 44f7d9492d98c4e95d06a3da3380f7bf892bc26c | more complete test
> configuration
> | parser | 2.0.2-SNAPSHOT | end of 2019 |
> 4df41f39b79827927256343f2652b078f6bb04f4 | mostly cleanup and dependency
> updates
> | security | 2.1.1-SNAPSHOT | end of 2021 |
> cacbef75a874c4ab489ed76489a1235b885b5f97 | some Java 8/11 optimizations
> TODO Should we remove hibernate, as we are not able to follow security
> updates and update hibernate to a current version? |
> | yaafi | 1.0.9-SNAPSHOT | end of 2018 |
> a931f52fbfca71c0a4a0f72ce8bc82e1ead80065 | mostly cleanup of tests and
> dependency updates
>
> What's your opinion? Do you agree? Did I miss something ?
>
> Should we wait and integrate / work on some important stuff? Should we
> just skip some Fulcrum updates? That is e.g. revert some dependencies in
> Turbine Core v5.2-SNAPSHOT (e.g. if we do not want the Java 11 baseline
> now in the new releases, we do not need parent 12)?
>
> Should we proceed and start with the release bundles as set out (that is
> as release first parent, then Fulcrum components and last Turbine-Core) ?
>
> Thanks!
>
> Best regards,
>
> Georg
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@turbine.apache.org
For additional commands, e-mail: dev-help@turbine.apache.org