jQuery plugin version scheme

[eguti...@cloudbees.com]

Hello all,

Jquery Jenkins plugin's version scheme matches the jQuery library version scheme, so that anyone adding the plugin automatically knows which jQuery version is being included.

This, though practical, does not follow Jenkins versioning convention and thus does not work well with several tools/libraries which understand this convention as existing. Such is the case of:

• VersionNumber library.
• Plugin Compatibility Tester

What do you think of releasing the current release adapting properly the version scheme (so that the two releases with the same content but different versions coexist) and, from now on, use the new version scheme for future releases?

Best regards,

Evaristo.

[Daniel Beck]

> On 12. Jun 2017, at 10:23, eguti...@cloudbees.com wrote:
>
> What do you think of releasing the current release adapting properly the version scheme (so that the two releases with the same content but different versions coexist) and, from now on, use the new version scheme for future releases?

What is the impact of this? I'd rather see the tools fixed (or at least an attempt at this) than trying to have everyone agree on a versioning scheme. For, Build Monitor View uses a "+build.201701152243" suffix, isn't that the same problem?

[Evaristo Gutierrez]

@Daniel what do you mean with the impact? As far as I know it would be just a new version, which does not seem to be harmful as the content is the same.

The thing is I don't think the tools are broken: the fact that several of them require the same version scheme, makes me think that such version scheme is already in place but is not being followed in some occasions. Taking into account specific and special cases, which can be unlimited (you for example just found another one), just make the tools obscure and less maintainable from my point of view.

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/qpXChF4R2Ro/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/B9D29E29-C245-47E2-A0D6-B122403C36F6%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

--

Best regards,

Evaristo.

[Daniel Beck]

> On 13. Jun 2017, at 09:57, Evaristo Gutierrez <eguti...@cloudbees.com> wrote:
>
> @Daniel what do you mean with the impact?

What is the motivation to change things here? How does that versioning scheme result in those tools not working properly?

[Evaristo Gutierrez]

Summarizing: PCT gathers dependencies for a plugin and adds the necessary ones to a modified plugin POM. To process the version of such dependencies, VersionNumber library is being used and it always returns version tokens split by '.'. The result is a wrong version is added to the POM and then the artifact cannot be gathered.

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/qpXChF4R2Ro/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/C0251B45-0F9A-42CE-A8F5-385716743F1C%40beckweb.net.

For more options, visit https://groups.google.com/d/optout.

--

Best regards,

Evaristo.

[Oleg Nenashev]

Hi,

This, though practical, does not follow Jenkins versioning convention and thus does not work well with several tools/libraries which understand this convention as existing.

There is no versioning convention in Jenkins. If PCT does custom version matching logic, maybe you may have to add more flexibility/hacks there

For Library wrapper plugins like jQuery I would vote for staying on the current approach when the plugins version equals to the bundled lib version.

BR, Oleg

 

вторник, 13 июня 2017 г., 11:32:33 UTC+2 пользователь Evaristo Gutierrez написал:

Summarizing: PCT gathers dependencies for a plugin and adds the necessary ones to a modified plugin POM. To process the version of such dependencies, VersionNumber library is being used and it always returns version tokens split by '.'. The result is a wrong version is added to the POM and then the artifact cannot be gathered.

On Tue, Jun 13, 2017 at 10:57 AM, Daniel Beck <m...@beckweb.net> wrote:

> On 13. Jun 2017, at 09:57, Evaristo Gutierrez <eguti...@cloudbees.com> wrote:
>
> @Daniel what do you mean with the impact?

What is the motivation to change things here? How does that versioning scheme result in those tools not working properly?

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/qpXChF4R2Ro/unsubscribe.

To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/C0251B45-0F9A-42CE-A8F5-385716743F1C%40beckweb.net.

For more options, visit https://groups.google.com/d/optout.

--

Best regards,

Evaristo.

[Manuel Jesús Recena Soto]

Hello Oleg,

2017-06-14 8:32 GMT+02:00 Oleg Nenashev <o.v.ne...@gmail.com>:

Hi,

This, though practical, does not follow Jenkins versioning convention and thus does not work well with several tools/libraries which understand this convention as existing.

There is no versioning convention in Jenkins. If PCT does custom version matching logic, maybe you may have to add more flexibility/hacks there

The convention is "you can use what you want while the Jenkins infrastruture (UCs, ATH, etc..) works properly".

What do you think?

IMHO, It would be easier to release this wrapper plugin following the most used format, instead of applying more hacks in the PCT.

Regards,

 

For Library wrapper plugins like jQuery I would vote for staying on the current approach when the plugins version equals to the bundled lib version.

BR, Oleg

 

вторник, 13 июня 2017 г., 11:32:33 UTC+2 пользователь Evaristo Gutierrez написал:

Summarizing: PCT gathers dependencies for a plugin and adds the necessary ones to a modified plugin POM. To process the version of such dependencies, VersionNumber library is being used and it always returns version tokens split by '.'. The result is a wrong version is added to the POM and then the artifact cannot be gathered.

On Tue, Jun 13, 2017 at 10:57 AM, Daniel Beck <m...@beckweb.net> wrote:

> On 13. Jun 2017, at 09:57, Evaristo Gutierrez <eguti...@cloudbees.com> wrote:
>
> @Daniel what do you mean with the impact?

What is the motivation to change things here? How does that versioning scheme result in those tools not working properly?


--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/qpXChF4R2Ro/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/C0251B45-0F9A-42CE-A8F5-385716743F1C%40beckweb.net.

For more options, visit https://groups.google.com/d/optout.

--

Best regards,

Evaristo.

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/05cc6f5c-3ba6-4dc2-803a-cdb6b1392ce2%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Manuel Recena Soto
* manuelrecena.com [/blog]
* linkedin.com/in/recena

[Oleg Nenashev]

The convention is "you can use what you want while the Jenkins infrastruture (UCs, ATH, etc..) works properly".

It would be good if somebody standardizes it, so far there is no convention.

Regarding this particular plugin, I think it is better to stick to jQuery versioning though it's up to the plugin maintainer

To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CABa-UodgN9GzS-zvTqZcDbRvu%2Bcd3v6%3DxoYBinB3Nr4drUgQ7g%40mail.gmail.com.

[Daniel Beck]

> On 2. Jul 2017, at 19:05, Manuel Jesús Recena Soto <rec...@gmail.com> wrote:
>
> IMHO, It would be easier to release this wrapper plugin following the most used format, instead of applying more hacks in the PCT.

The "hack" being a library upgrade to a version not several years out of date?

https://github.com/jenkinsci/plugin-compat-tester/pull/32 does not look like a hack to me...

[Manuel Jesús Recena Soto]

Oleg,

Standardization is key principle in this kind of projects ;)

Daniel,

I agree with you. I did not remember that this version format was supported by https://github.com/jenkinsci/lib-version-number

Thank you for your feedback.

--
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+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/F947A69A-5843-4F01-AAAA-C6F03810C6F6%40beckweb.net.

For more options, visit https://groups.google.com/d/optout.