We were thinking of renaming jdk19 to jdk-edge and have this version
following all new jdk versions almost automatically. And in the same time,
modifying the buildpluging to build on this one too but without failing ...
just informative (except if a specific flag is set to true, like
failonedge:
What Tim said. I am not the biggest fan of an edge label either as
this goes against the principle of reproducible builds. The Java 19
agent label can be deprecated in the agent documentation when Java 20
is released (which is minimal effort on the operational side). In
general consumers of
Personally I'm not the biggest fan of edge I'd rather get a clear error
that the Java version has been removed or a deprecation error in my build
than the Java versions has been randomly changed to another major version.
I think that we would want a deprecation period after 20 is out (and maybe
On Wed, Dec 7, 2022 at 11:20 AM Alexander Brandes
wrote:
> There's no support for automated releases (CD, JEP-229), missing metadata
> for the plugin page and a few other limitations, which don't make it a
> great experience using it.
> …
> I would be ready to lift this restriction again if the
+1 for the edge approach, to not create "superficial" tech debt
On Thursday, December 8, 2022 at 8:34:12 AM UTC-8 slide wrote:
> I think the edge idea is a good one. This reduces the churn on Jenkinsfile
> changes to support building on the latest. It would be nice if we, as
> plugin
+1
On Thursday, December 8, 2022 at 8:27:13 AM UTC-8 Adrien Lecharpentier
wrote:
> +1 as well from me.
>
> Le jeu. 8 déc. 2022 à 17:19, Damien Duportal a
> écrit :
>
>> +1
>>
>> Le mercredi 7 décembre 2022 à 15:49:42 UTC+1, bma...@gmail.com a écrit :
>>
>>> +1.
>>>
>>> At least such a move
I think the edge idea is a good one. This reduces the churn on Jenkinsfile
changes to support building on the latest. It would be nice if we, as
plugin developers, could opt in to failures on the edge or not, meaning
that a build failure on the latest jdk would not cause the build to fail,
unless
+1 as well from me.
Le jeu. 8 déc. 2022 à 17:19, Damien Duportal a
écrit :
> +1
>
> Le mercredi 7 décembre 2022 à 15:49:42 UTC+1, bma...@gmail.com a écrit :
>
>> +1.
>>
>> At least such a move will make it very explicit for any new plugin that
>> only Maven really has /production/ support for
+1
Le mercredi 7 décembre 2022 à 15:49:42 UTC+1, bma...@gmail.com a écrit :
> +1.
>
> At least such a move will make it very explicit for any new plugin that
> only Maven really has /production/ support for Jenkins plugin dev.
>
> I think that we should still "allow" new plugins to use Gradle
> Given this is the first time (I think) that a non-LTS JDK is provided,
what are the plans around supporting this?
We did not have any plan as we did not thought that much. Interesting point!
> Will it be removed once JDK 20 exists?
I guess yes. That would break pipelines using JDK19 though.
On Thu, Dec 8, 2022 at 11:02 AM 'Stephane Merle' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:
> Hello dear developers,
>
> I’m happy to announce that in order to allow contributors to prepare the
> future of Jenkins by working in advance with new JDK, we’ve added JDK19 on
>
As explained by Jesse in
https://github.com/jenkins-infra/pipeline-library/pull/541#issuecomment-1342884874,
changing the default of buildPlugin() could create problems. I'll close the
PR as there is no value in changing the default as it.
The archetypes used to generate a new plugin project
That's great, thanks a lot, Jenkins Infra team.
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this
Hello dear developers,
I’m happy to announce that in order to allow contributors to prepare the
future of Jenkins by working in advance with new JDK, we’ve added JDK19 on
ci.jenkins.io.
Multiple options are available,
- with the new tools installer 'jdk19', though the buildPlugin()
14 matches
Mail list logo