I guess we all agree on that so we just need to write it then? Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 21 avr. 2021 à 13:18, Gary Gregory <[email protected]> a écrit : > Well said Ralph :-) > > Gary > > On Wed, Apr 21, 2021, 02:26 Ralph Goers <[email protected]> > wrote: > > > FWIW, I prefer that a project (any project, not just Maven) have a > > documented versioning policy that says something like “We use Semantic > > Versioning [1]. We don’t skip version numbers for things someone said a > > future release might contain. We do have guidance that specifies what is > > guaranteed to be backward compatible and what is not. That guidance is > …”. > > > > That said, a release manager is pretty much always free to do what they > > choose. It is up to the PMC to accept or reject a release based on > whatever > > criteria the PMC has decided upon. > > > > In the end though, I am going to support those who are doing the hard > work. > > > > Ralph > > > > [1] https://semver.org/ > > > > > On Apr 20, 2021, at 11:12 AM, Romain Manni-Bucau < > [email protected]> > > wrote: > > > > > > Well, i'd like we close this topic by an action and not let it die if > > > possible. > > > That said, as mentionned originally, what I want we write and publish > is > > > what we guarantee. > > > I tried to write what i'd like to see/would expect as an user but if > the > > > agreement is that there will be no guarantee i'm fine with that too - > > would > > > be happy to have some help on the wording for such a statement though. > > > This kind of statement also solves the issue and would close this > thread > > > for me. > > > > > > I like the idea of Benjamin of listing support companies but I think it > > is > > > worth another page maybe (linked from the previous one/history page > Hervé > > > mentionned). > > > > > > Would this kind of solution work for everybody? To be concrete: > > > > > > 1. we write on history page that there is no guarantee of version for a > > > security fix (Ex: if the fix requires a new feature it will likely not > > hit > > > a patch release but a minor one using semver semantic) > > > 2. we create a support page > > > > > > Wdyt? > > > > > > Romain Manni-Bucau > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > <https://rmannibucau.metawerx.net/> | Old Blog > > > <http://rmannibucau.wordpress.com> | Github < > > https://github.com/rmannibucau> | > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > > < > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > > > > > Le mar. 20 avr. 2021 à 20:03, Benjamin Marwell <[email protected]> a > > > écrit : > > > > > >> I tend to agree to Robert, although I find your idea appealing and do > > >> understand the motivation. > > >> > > >> If you look at some Eclipse projects, they also refer you to companies > > like > > >> IBM if you want anything beyond [1]. > > >> > > >> Ben > > >> > > >> [1]: e.g. > > >> https://adoptopenjdk.net/support.html > > >> > > >> On Tue, 20 Apr 2021, 19:55 Robert Scholte, <[email protected]> > > wrote: > > >> > > >>> Romain, > > >>> > > >>> I still don't like this approach. > > >>> > > >>> What you're asking tend to look like contracts and SLA's and as long > as > > >>> we're maintaining Maven with a very small group of volunteers and > > aren't > > >>> backed full time by some company we shouldn't do this. > > >>> If there are companies that use Maven and want this kind of > commitment, > > >> we > > >>> need to start a different discussion. > > >>> E.g. could/should I (or any other Maven developer) start to offer > Maven > > >>> Support contracts and under what conditions? > > >>> > > >>> Keep in mind that you are the only that keeps pushing this topic. > > >>> I noticed that it frustrates some and that it they loose their > > motivation > > >>> to work on Maven. > > >>> Please reconsider if it is still worth the discussion or that you can > > >>> solve it for yourself. > > >>> > > >>> thanks, > > >>> Robert > > >>> On 19-4-2021 20:05:53, Romain Manni-Bucau <[email protected]> > > wrote: > > >>> Le lun. 19 avr. 2021 à 17:20, Benjamin Marwell a > > >>> écrit : > > >>> > > >>>>> Do we write 3.6 and 4 are active and maintained branches currently > or > > >>>> do we > > >>>>> drop 3.x with first 4.x release? > > >>>> > > >>>> Dropping 3.x with the first 4.x release would not make sense from > the > > >>>> point you presented earlier. > > >>>> I'd drop 3.x as soon as we reach 4.1.0. > > >>>> > > >>> > > >>> I can agree but it also means we define what is 4.1.0 and since we > > "jump" > > >>> versions it will require us to better respect what we plan (I think > it > > is > > >>> very good, don't take it wrong). > > >>> > > >>> > > >>>> > > >>>>> maintenance branches on demands > > >>>> My vote would be to cherry pick security fixes for the previous > minor > > >>>> version. > > >>>> E.g. if we release 4.0.1, also release a 3.8.2 (assuming the current > > >>>> latest versions are 4.0.0. and 3.8.1). > > >>>> > > >>>> I mean, we can try this for a single release and see if we like it. > > >>>> If not, we can still drop this again and revert back to "on demand" > > >>>> maintenance branches. > > >>>> > > >>>> Backporting features does not make sense (imo) how maven treats > > >> releases. > > >>>> > > >>> > > >>> I think it is the whole point: what when we fix a security issue by a > > new > > >>> feature -> "does not make sense" (quoting your words but that's what > > was > > >>> the outcome for 3.8.1) and it is exactly the issue I face and I want > we > > >>> fix: no predictability on stable maven versions with a minimal > > >> maintenance > > >>> "guaranteed" (no security issue opened in CVE databases). > > >>> So I think we either write we backport the security fixes in last 2 > > >>> maintained branches with some duration (we can align on java LTS > > duration > > >>> for example which should be close to our major breaking changes) or > we > > >>> write we don't care and only maintain the last release branch and it > is > > >> the > > >>> only one guaranteed to get fixes (which kind of means there will be > no > > >>> anticipation of version but it is known upfront). > > >>> Indeed I'm not a fan of such "you will see" policies but it clarifies > > the > > >>> point which is my main blocker at the moment at least we can justify > > our > > >>> last behavior. > > >>> This is really the answer I'm after: explicit what we do and continue > > or > > >>> make us more rigorous in the future. > > >>> > > >>> That said I note the "we can still revert back" point which is > surely a > > >>> very good one so idea can be to write "we will do xxxx" and add a > > banner > > >> on > > >>> top saying "experimental policy until XXXX" (for example for a year) > > and > > >> we > > >>> can change the policy (and update the deadline) within this duration > if > > >> it > > >>> does not fit. This would enable us to test and validate the policy > with > > >> an > > >>> error right and let the user know it upfront. > > >>> > > >>> So proposal can be: > > >>> > > >>> [Experimental policy until June 2022] > > >>> 1. We maintain two major releases, ie 3.x and 4.x as of today (no > minor > > >> in > > >>> particular, just the highest one) > > >>> 2. We maintain versions and notify the EOL 3 years before it is > reached > > >> (so > > >>> if we want to EOL v3 in 2025 we will notify users in 2022) > > >>> 3. We backport and release security fixes (new feature or not) in all > > >>> maintained branches > > >>> > > >>> Wdyt? > > >>> > > >>> > > >>>> > > >>>> Am So., 18. Apr. 2021 um 22:45 Uhr schrieb Romain Manni-Bucau > > >>>> : > > >>>>> > > >>>>> Hi all, > > >>>>> > > >>>>> Back on this topic - which prepares v4 releases too btw. > > >>>>> > > >>>>> What do we finally write? > > >>>>> > > >>>>> That maven will always fix the latest (stable) version and can > > >> release > > >>>>> maintenance branches on demands (lazily)? > > >>>>> > > >>>>> Do we write 3.6 and 4 are active and maintained branches currently > or > > >>> do > > >>>> we > > >>>>> drop 3.x with first 4.x release? > > >>>>> > > >>>>> Indeed I'd like the 2 branches option but I am fine with whatever > > >>> policy > > >>>>> while written and clear for end users upfront. I'd love we solve > that > > >>>>> before next release if possible cause it always create pointless > work > > >>> due > > >>>>> to the blurry exchanges on this topic over our website and the > > >> net/mail > > >>>>> archives. > > >>>>> > > >>>>> > > >>>>> Le lun. 5 avr. 2021 à 19:51, Romain Manni-Bucau > > >>>> a > > >>>>> écrit : > > >>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Le lun. 5 avr. 2021 à 17:42, Ralph Goers > > >>>> a > > >>>>>> écrit : > > >>>>>> > > >>>>>>> I don’t understand the point. The very next version of Maven did > > >> get > > >>>> the > > >>>>>>> security fix. Just because the release manager decided to follow > a > > >>>> peculiar > > >>>>>>> version numbering practice unique to Maven doesn’t mean there is > a > > >>>> problem. > > >>>>>>> > > >>>>>> > > >>>>>> This had been an issue only because the versioning policy of maven > > >> is > > >>>>>> undefined. > > >>>>>> If defined it is perfectly fine for me. > > >>>>>> > > >>>>>> > > >>>>>>> > > >>>>>>> I don’t know what you mean by random, nor do I know what you mean > > >>> by a > > >>>>>>> stability statement. AFAIK Maven has been very stable from the > 2.x > > >>>> versions > > >>>>>>> through the 3.x versions. In some ways too stable, which is why > > >>>> introducing > > >>>>>>> new concepts that have been wanted for years is so hard. > > >>>>>>> > > >>>>>> > > >>>>>> Last statements tend to mean that once 4.x will be there, 3.x will > > >> be > > >>>>>> forgotten and no more maintained. > > >>>>>> Since it is a breaking change and if you picked 3.x today it is a > > >> big > > >>>> deal > > >>>>>> since you have no guarantee you can upgrade without a lot of > > >>>> investment and > > >>>>>> get security fixes when needed by just upgrading (and potentially > > >>>> tuning a > > >>>>>> bit the conf but not by rewriting the poms for ex). > > >>>>>> > > >>>>>> For 2.x -> 3.x time, the 2.x was maintained some years. > > >>>>>> This is very close to the LTS concept, and this is mainly this > kind > > >>> of > > >>>>>> statement I'm trying to get to let projects plan properly and not > > >>> have > > >>>>>> maven on their road too easily. > > >>>>>> If properly defined it will not impact much maven dev but can save > > >> a > > >>>> lot > > >>>>>> of time for enterprises and enable them to properly setup their > > >>>> projects in > > >>>>>> time. > > >>>>>> > > >>>>>> So overall the definition points are still the same: > > >>>>>> > > >>>>>> 1. which versions are maintained (ie can get security fixes - new > > >>>> features > > >>>>>> are not required to be in the box here) > > >>>>>> 2. for how long > > >>>>>> 3. what does mean version (major.minor.*, major.* for ex) in 1. > > >>>>>> > > >>>>>> "3.x will be supported for 3 more years when 4.x is out and > > >>> maintained > > >>>>>> major versions are guaranteed to get security fixes" is a kind of > > >>>> statement > > >>>>>> which solves that - we can also use N=current and N+1 in the > > >>> statement > > >>>> to > > >>>>>> not stick it to 3 and 4. > > >>>>>> "4.x is the current released branch, other branch will never be > > >>>> released > > >>>>>> anymore" does not work for me for example IMHO (but we can put it > > >> on > > >>>> vote > > >>>>>> if that's the community desire). > > >>>>>> > > >>>>>> > > >>>>>>> > > >>>>>>> FWIW, my employer’s repository manager still uses http since it > is > > >>>> behind > > >>>>>>> a VPN. After trying 3.8.1 I found I had to specify mirrors for > all > > >>> the > > >>>>>>> repos even though they are not defined in pom’s. Apparently the > > >> fix > > >>>> also > > >>>>>>> affects repositories defined in settings.xml. > > >>>>>>> > > >>>>>> > > >>>>>> Yes because it is a mirror and wildcard one. > > >>>>>> Using a custom global settings - to override default one - is a > > >>>> solution > > >>>>>> if you know all http repositories you want to force to be blocked > > >>> (can > > >>>> be > > >>>>>> hard since you never know all of them by definition and mirroring > > >>> does > > >>>> not > > >>>>>> support custom patterns but can be a quick workaround to upgrade > > >>>> without > > >>>>>> blocking builds). > > >>>>>> > > >>>>>> > > >>>>>>> > > >>>>>>> Ralph > > >>>>>>> > > >>>>>>>> On Apr 5, 2021, at 12:28 AM, Romain Manni-Bucau > > >>>> [email protected]> > > >>>>>>> wrote: > > >>>>>>>> > > >>>>>>>> Hmm, general/common asf way of doing is to move forward until > > >>> users > > >>>> ask > > >>>>>>>> (and if so any branch is patched while a pr is done). > > >>>>>>>> If maven does not follow that practise it cant say "last version > > >>>> will > > >>>>>>> get > > >>>>>>>> the security fix" too because it means "we dont care of users, > > >> to > > >>>> get > > >>>>>>> the > > >>>>>>>> cve fix you will have to rewrite your build". > > >>>>>>>> So at least a major stability statement is required IMO with > > >> some > > >>>> lts > > >>>>>>>> statement and eol on majors. > > >>>>>>>> Without that using maven sounds random for projects, no? > > >>>>>>>> > > >>>>>>>> Le dim. 4 avr. 2021 à 22:13, Bernd Eckenfels > > >>>> [email protected]> a > > >>>>>>>> écrit : > > >>>>>>>> > > >>>>>>>>> I agree, maven does not need to concern itself with branches as > > >>>> long > > >>>>>>> as it > > >>>>>>>>> stays fairly forward drop-in compatible. > > >>>>>>>>> > > >>>>>>>>> Having said that, things like changing the policy for handling > > >>> http > > >>>>>>> might > > >>>>>>>>> not be that drop-in, but on the other hand it’s just a config > > >>>> option > > >>>>>>> and > > >>>>>>>>> does not require complicated (plugin) dependency updates. > > >>>>>>>>> > > >>>>>>>>> I do wonder if the version number should better reflect such > > >>>>>>> incompatible > > >>>>>>>>> requirement changes. (And if somebody really wants to provide > > >>>> security > > >>>>>>>>> fixes for those incompatible older branches why not, but I > > >> don’t > > >>>> think > > >>>>>>> you > > >>>>>>>>> can require them from a project which does not offer them by > > >>>> themself). > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> -- > > >>>>>>>>> http://bernd.eckenfels.net > > >>>>>>>>> ________________________________ > > >>>>>>>>> Von: Ralph Goers > > >>>>>>>>> Gesendet: Sunday, April 4, 2021 9:55:50 PM > > >>>>>>>>> An: Maven Developers List > > >>>>>>>>> Betreff: Re: Security/Versioning policy proposal > > >>>>>>>>> > > >>>>>>>>> More than likely you will get whatever the next version number > > >>>> happens > > >>>>>>> to > > >>>>>>>>> be. I can’t think of a case where Maven needed to go back and > > >>>> patch a > > >>>>>>> prior > > >>>>>>>>> release. That could happen however, if Maven was modified to > > >>>> require > > >>>>>>> Java > > >>>>>>>>> 11 to run and a security fix had to be applied to the last > > >>> version > > >>>>>>>>> supporting Java 8. > > >>>>>>>>> > > >>>>>>>>> Ralph > > >>>>>>>>> > > >>>>>>>>>> On Apr 4, 2021, at 6:25 AM, Romain Manni-Bucau > > >>>> [email protected] > > >>>>>>>> > > >>>>>>>>> wrote: > > >>>>>>>>>> > > >>>>>>>>>> Le dim. 4 avr. 2021 à 14:10, Robert Scholte > > >>>> a > > >>>>>>>>> écrit : > > >>>>>>>>>> > > >>>>>>>>>>> To me all releases can contain security fixes. > > >>>>>>>>>>> Depending on the risk of the CVE we can decide to do a > > >> release > > >>>> with > > >>>>>>> only > > >>>>>>>>>>> those fixes (see Maven 3.0.5 and 3.8.1) > > >>>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> I get that but it does not help users to pick versions and to > > >>> get > > >>>> any > > >>>>>>>>>> stability in their build - which is the goal of this thread. > > >>>>>>>>>> Since you rejected a 3.6.4 for last CVE hitting us I have to > > >>>> admit I > > >>>>>>>>> have a > > >>>>>>>>>> hard time to formalize it. > > >>>>>>>>>> Best I come up is "we'll do what we want" which is hopefully > > >>> just > > >>>> a > > >>>>>>>>>> complete misinterpretation of what you mean but hope shows how > > >>>>>>> clueless I > > >>>>>>>>>> am with such a statement at the moment. > > >>>>>>>>>> Can you try to refine it please? > > >>>>>>>>>> > > >>>>>>>>>> Concretely, today I'm starting with a 3.8.1, what am I > > >> expecting > > >>>> to > > >>>>>>> use > > >>>>>>>>> in > > >>>>>>>>>> 5 years for this project trying to get security fixes and > > >> being > > >>>> stable > > >>>>>>>>> (ie > > >>>>>>>>>> 4.x is assumed excluded?)? > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> Robert > > >>>>>>>>>>> > > >>>>>>>>>>> On 4-4-2021 12:14:39, Romain Manni-Bucau > > >>>>>>> wrote: > > >>>>>>>>>>> Le dim. 4 avr. 2021 à 12:09, Robert Scholte a écrit : > > >>>>>>>>>>> > > >>>>>>>>>>>> I doubt we can or should make any promises, only intentions. > > >>>>>>>>>>>> If we would have it, I wonder if it cover our choice to skip > > >>>> 3.7.0. > > >>>>>>>>>>>> To me we need to keep that flexibility. > > >>>>>>>>>>>> > > >>>>>>>>>>>> I want to reverse the approach: what could users expect as > > >>>>>>> differences > > >>>>>>>>>>>> between version x and y. > > >>>>>>>>>>>> > > >>>>>>>>>>>> For Maven shouldn't be more complex than: > > >>>>>>>>>>>> bugfix release-change should be safe "just replace" release > > >>> with > > >>>>>>>>> bugfixes > > >>>>>>>>>>>> and internal improvements. > > >>>>>>>>>>>> minor release-change should represent relevant new features > > >> or > > >>>> (as > > >>>>>>> we > > >>>>>>>>> saw > > >>>>>>>>>>>> for 3.8.x) possible breaking builds that can be fixed with > > >>>>>>>>> configuration. > > >>>>>>>>>>>> major release-change represents changes to the architecture > > >>> that > > >>>>>>> might > > >>>>>>>>>>>> change the behavior. > > >>>>>>>>>>>> as far as I know this defends all Maven releases up until > > >> now. > > >>>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> Does not cover the last release - and is actually the issue > > >> I'm > > >>>>>>>>> suffering > > >>>>>>>>>>> from right now and why i'd like we cover this case: security > > >>>> fixes. > > >>>>>>> As > > >>>>>>>>> of > > >>>>>>>>>>> today it is a mix between patch (bugfix) and minor lines > > >> AFAIK > > >>>> but > > >>>>>>> I'd > > >>>>>>>>> like > > >>>>>>>>>>> we explicit it (even just saying on each line "can include > > >>>>>>> bugfixes"). > > >>>>>>>>>>> Said differently: the reverse approach you mention only cover > > >>> the > > >>>>>>>>> feature > > >>>>>>>>>>> evolution but not the most important for versioning policy: > > >> the > > >>>>>>> security > > >>>>>>>>>>> policy which is the one which hurt right now. > > >>>>>>>>>>> As an user, I want to be able to anticipate the versions i > > >> can > > >>>> need > > >>>>>>>>> staying > > >>>>>>>>>>> as much as possible on a stable version (original version) > > >> but > > >>>>>>>>> upgrading to > > >>>>>>>>>>> get security fixes. > > >>>>>>>>>>> If it is fine for you to mention lines 1 and 2 can include > > >>>> security > > >>>>>>>>> fixes > > >>>>>>>>>>> i'd be to add this paragraph on the history page maybe? > > >>>>>>>>>>> > > >>>>>>>>>>> wdyt? > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>>> In case of plugins: the major represents the minimal > > >> required > > >>>>>>> version > > >>>>>>>>> of > > >>>>>>>>>>>> Maven. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Robert > > >>>>>>>>>>>> On 4-4-2021 11:28:30, Romain Manni-Bucau wrote: > > >>>>>>>>>>>> Hi Elliotte, > > >>>>>>>>>>>> > > >>>>>>>>>>>> My goal is to write what we can promise and users can rely > > >> on > > >>> to > > >>>>>>> work. > > >>>>>>>>>>>> If we can only promise any major release will get all > > >> security > > >>>> fixes > > >>>>>>>>>>>> whatever are the minor/patch versions, be it. > > >>>>>>>>>>>> I just want what we do to be explicit. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Hervé proposed to reference history page of website, it can > > >>> be a > > >>>>>>> good > > >>>>>>>>>>> start > > >>>>>>>>>>>> with one or two more sentences to solve that. > > >>>>>>>>>>>> > > >>>>>>>>>>>> Le sam. 3 avr. 2021 à 23:50, Elliotte Rusty Harold a > > >>>>>>>>>>>> écrit : > > >>>>>>>>>>>> > > >>>>>>>>>>>>> On Fri, Apr 2, 2021 at 4:21 PM Romain Manni-Bucau > > >>>>>>>>>>>>> wrote: > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Hi all, > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> What about starting from something like > > >>>>>>>>>>>>>> http://tomee.apache.org/security/security.html for our > > >>>> versioning > > >>>>>>>>>>>>> policy. > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Goal is really to let user plan their versioning policy > > >> and > > >>>> ensure > > >>>>>>>>>>>> there > > >>>>>>>>>>>>> is > > >>>>>>>>>>>>>> no big surprises in the needed upgrades to have bugfixes. > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> TBH I don't think we have enough developer time and > > >>> commitment > > >>>> to > > >>>>>>>>>>> promise > > >>>>>>>>>>>>> this. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> -- > > >>>>>>>>>>>>> Elliotte Rusty Harold > > >>>>>>>>>>>>> [email protected] > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>> > > >>> --------------------------------------------------------------------- > > >>>>>>>>>>>>> To unsubscribe, e-mail: [email protected] > > >>>>>>>>>>>>> For additional commands, e-mail: [email protected] > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>> > --------------------------------------------------------------------- > > >>>>>>>>> To unsubscribe, e-mail: [email protected] > > >>>>>>>>> For additional commands, e-mail: [email protected] > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>> --------------------------------------------------------------------- > > >>>>>>> To unsubscribe, e-mail: [email protected] > > >>>>>>> For additional commands, e-mail: [email protected] > > >>>>>>> > > >>>>>>> > > >>>> > > >>>> > --------------------------------------------------------------------- > > >>>> To unsubscribe, e-mail: [email protected] > > >>>> For additional commands, e-mail: [email protected] > > >>>> > > >>>> > > >>> > > >> > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
