In my mind, this is simple: features go into major and minor versions,
maintenance versions are only for bugs, therefore a feature change is not
done in a maintenance version.
Gary
On Sun, Mar 28, 2021, 05:47 Romain Manni-Bucau
wrote:
> Hi all,
>
> Before we reroll the failed 3.8.0 I'd like we
So seems there are two points to refine:
1. Is the http change *without as such toggle* a security fix (3.6) or
feature (3.7 or 3.8)
2. Do we fully reject semver and use 2 digit versioning (seems it is what
we often do).
On 1 im clearly for the security fix.
On 2 i dont care but we should
Nonsense. It is common sense that most criminal acts are spawned from within
the local network, due to social engineering.
-Markus
-Ursprüngliche Nachricht-
Von: Som Lima [mailto:somplastic...@gmail.com]
Gesendet: Sonntag, 28. März 2021 15:06
An: Maven Developers List
Betreff: Re:
3.8.1 as we already burned and accidentally released 3.8.0
Though if we could go back in time to before the vote was started, it
should have been 3.6.4 IMO... but since the release manager went with
3.8.0, that’s the train we’re on
FTR the release manager’s decision on version number has always
> BTW there should be an option to still use unsecure http as many people
run http in their LANs.
I could be wrong but I think the intranet is a tightly coupled comm system
therefore it is secure by design.
On Sun, 28 Mar 2021, 13:31 Markus KARG, wrote:
> We should not do any tricks or
>> - Why not 3.7.0?
>> Apache Maven 3.7.0 has been advertised in the past that it would be the
>> first release where you could optionally activate the build/consumer
>> feature: the version containing this feature has been renamed to 4.0.0.
>> Reusing 3.7.0 might lead to confusion, hence we
We should not do any tricks or unexpected behavior but just stick with SemVer.
If there is a need for a security fix, it has to be 3.6.4 and BTW there should
be an option to still use unsecure http as many people run http in their LANs.
If it contains backwards-compatible features, it has to be
Am 2021-03-28 um 11:47 schrieb Romain Manni-Bucau:
Hi all,
Before we reroll the failed 3.8.0 I'd like we discuss openly the next
versioning since it seems we didn't reach a consensus yet and trying to
not
create too much friction for users and in the community.
As a reminder the only
On Sun, 28 Mar 2021 at 8:07 pm, Hervé BOUTEMY wrote:
> thank you Romain for your view
>
> current reasoning behind 3.8.0 choice is written in release notes [1]
>
> - Why not 3.6.4?
> This is not just a bugfix as it contains three features that cause a
> change of default behavior (external HTTP
Thanks for clearing that up.
One step closer to choosing
the version number.
On Sun, 28 Mar 2021, 12:05 Tibor Digana, wrote:
> Hi Som Lima,
>
> Regarding (1), the Maven Central works with HTTPS for some time already.
> Regarding the Repository Managers, e.g. Nexus or JFrog they have to be
>
Hi Som Lima,
Regarding (1), the Maven Central works with HTTPS for some time already.
Regarding the Repository Managers, e.g. Nexus or JFrog they have to be
updated to HTTPS in companies which is normal work for the administrators
and devops teams, not for the users or devs, but nowadays the
Side note: was reviewing TomEE versioning policy which is very very close
to what we find in most companies having a versioning policy for security
vulnerabilities (https://tomee.apache.org/security/) and it tends to show
that the 3.6 handling would be a 3.6.3.1 with the security fix. Maybe an
As a user these points would be MAJOR concerns
1. external HTTP insecure URLs are now blocked by default
2. your builds may fail when using this new Maven release.
I would say go for version 5.0 suggesting a fresh start. A clear separation.
Leaving you enough versions to fix 3.6.3 bugs where
Hi Hervé,
What about the 3.6.4 with this fix need anyway (to be clear: security fixes
must be backported in ~LTS, ie 3.6 as of today - even if we can't have such
statement it is needed in practise anyway? I don't clearly read in your
answer what's would be the plan to manage it. To try to be very
thank you Romain for your view
current reasoning behind 3.8.0 choice is written in release notes [1]
- Why not 3.6.4?
This is not just a bugfix as it contains three features that cause a change of
default behavior (external HTTP insecure URLs are now blocked by default): your
builds may fail
Hi all,
Before we reroll the failed 3.8.0 I'd like we discuss openly the next
versioning since it seems we didn't reach a consensus yet and trying to not
create too much friction for users and in the community.
As a reminder the only feature the release will get is to prevent HTTP repo
(in favor
Thanks.
I think I am going to feel like a fool
If this works as I want it to.
import org.apache.maven.cli.MavenCli;
import java.io.File;
/**
* @author Mariusz Smykula
*/
public class MavenClient {
public static void main(String[] args) {
System.out.println(new File(".").getAbsolutePath());
Yes, there is an API to embed Maven.
-Markus
-Ursprüngliche Nachricht-
Von: Som Lima [mailto:somplastic...@gmail.com]
Gesendet: Sonntag, 28. März 2021 06:26
An: dev@maven.apache.org
Betreff: Running maven from inside JVM.
Hi,
Is it possible to run maven from inside JVM ?
i.e.
Java
18 matches
Mail list logo
