Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

versions:use-latest-releases updates to the highest version number but not to recent release #263

Closed
habdank opened this issue Mar 8, 2018 · 2 comments

Comments

@habdank
Copy link

habdank commented Mar 8, 2018

Hi,

There is the following situation the last release of the javax.mail:mail is 1.4.7 which (as of 2018-03-08) is the newest, but there is already existing beta: 1.5.0-b01

The maven versions:use-latest-releases blindly goes over just numbers and does not prove,
that 1.4.7 is newer in time and that -b01 is beta and not real release.

This is in my opinion very weak point ot this plugin.

It would be really great, when plugin can on its own separate releases from any kind of betas, which needs to be written over and over again in every project in form of well known ruleset.

Best regards,
Seweryn.

@nsidhaye
Copy link

nsidhaye commented Sep 5, 2018

@habdank : Refer #157 (comment)

@batmat
Copy link
Member

batmat commented Feb 15, 2019

It is using release in the general meaning of Maven, where basically there is either release, or a snapshot.
Betas are still releases in that meaning.

See link posted to the version rules config file. Apart even from the possible debate if beta or alphas should be selected by default, having that way to define those rules in your context seems to me like the only way to address the various situations in the world about this.

Given 1) there seems to me there's a clear path for your use case with configuring such "rules" and 2) we cannot probably reasonably change this behaviour by default without breaking the whole usages out there, I'm going to close this.

Now, feel free obviously to propose improvements around that. I think this would be still be acceptable to have something easy way to define simple rules for defining for instance a matching regex for what should be selected \o/. (not enabled by default, hence)

@batmat batmat closed this as completed Feb 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants