Because users need to learn the new format. The version number is not just for machines but for people too
On 20 June 2014 14:04, Igor Fedorenko <[email protected]> wrote: > > > On 2014-06-20, 7:59, Stephen Connolly wrote: > >> +1 on semver. >> >> Also if we change the schema or even the format (eg elements -> >> attributes, >> xml -> DSL, etc) then we also bump the major even if there is a 1:1 >> bijection >> >> > If newer Maven versions can fully interpret new format without any loss > of configuration, why does the format need major version bump? > > -- > Regards, > Igor > > > > > On Friday, 20 June 2014, Igor Fedorenko <[email protected]> wrote: >> >> I think ad-hoc aggregators are an interesting use case and I need to >>> think about it some more before I decide how I'd like to support it. >>> >>> Anyways, all changes I currently have in mind are additions to the model >>> and reading older formats will not be a problem. Lets decide what to do >>> with truly incompatible model changes when we have specific problem to >>> solve. >>> >>> But this got me thinking about something else. Can we agree on >>> semver-ish versioning scheme for pom formats? We increase minor part of >>> the format version to indicate perfect supersets, i.e. new features are >>> added but all old features continue to work as-is. We increase major >>> part when we remove supported elements or change meaning of existing >>> elements. >>> >>> -- >>> Regards, >>> Igor >>> >>> >>> On 2014-06-19, 20:22, Stephen Connolly wrote: >>> >>> On Friday, 20 June 2014, Igor Fedorenko <[email protected]> wrote: >>>> >>>> I am not sure I follow. >>>> >>>>> >>>>> Do you want to allow multi-module projects where different modules >>>>> require different versions of maven? >>>>> >>>>> >>>> >>>> No I want to allow multi-module projects where the maximum modelVersion >>>> defines the minimum required version of maven to build. >>>> >>>> >>>> If required version of maven is the same, why not require the same pom >>>>> format version for the entire build too? >>>>> >>>>> >>>> >>>> Because I may be working on several things that I am throwing together >>>> in >>>> a local aggregator pom... Because I am working on a module that I cannot >>>> change the build process for and another module at the same time that >>>> needs >>>> the newer features >>>> >>>> Are you concerned about changes >>>> >>>> to pom.xml files when moving from one format version to the next or >>>>> something else? >>>>> >>>>> >>>> >>>> I want to be able to migrate modules to newer build poms when they are >>>> ready to do so. That may mean that I have a project with one child that >>>> can >>>> be built by Maven 2.0 another that needs maven 3.2.2 and a 3rd that >>>> needs >>>> maven 4.1. To build that reactor I need to use maven 4.1 or newer... Or >>>> I >>>> can not use a reactor and push things to the local repo and build the >>>> first >>>> module with maven 2.0, change my PATH, build the second module with >>>> maven >>>> 3.2.2, change my PATH again and build the last module with Maven 4.1... >>>> All >>>> pushing to the local repo... Hoping that we haven't changed the local >>>> repo >>>> format... Hoping that I've remembered to do that all correctly, and all >>>> for >>>> the same feature branch... Oh I got distracted and had to switch to a >>>> different branch and back again... Sorry start at the beginning again >>>> just >>>> to be sure. >>>> >>>> Ok, so we can use something like RVM so that as we cd into each module >>>> we >>>> pick up an .mvnenv file that causes our PATH to auto switch... But >>>> really? >>>> And for this to work we have two choices... Never evolve the local repo >>>> OR >>>> run a local remote repo to act as a maven version neutral exchange... >>>> Great >>>> now I've gone from `mvn clean verify` to `cd foo && mvn clean deploy >>>> -DaltDeploymentUrl=... && cd ../bar && mvn clean deploy >>>> -DaltDeploymentUrl=... && cd ../manchu && ...` that's just great that >>>> is! >>>> >>>> I argue that unless we keep the contract that newer maven can build all >>>> older maven projects, then there is no point even calling new maven >>>> "maven"... >>>> >>>> Does it have to build them perfectly? Perhaps not, I can live with >>>> needing >>>> to tweak things to iron out an inconsistency as long as after the tweak >>>> both new and old build that module the same... So, for example, if the >>>> old >>>> pom references ${pom.artifactId} and new maven cannot build that unless >>>> you >>>> change it to ${project.artifactId} that is OK in my book as both forms >>>> are >>>> legal in old maven so switching to the new one will not break old >>>> maven... >>>> (Obviously better if we don't fail in that case... Just trying to give a >>>> concrete example) >>>> >>>> The reason is that there is a pressure keeping me from advancing that >>>> module to Maven 4.1. Don't force me to jump through hoops just because >>>> some >>>> a-hole is keeping that module shackled to build with Maven 2.0.6 levels >>>> of >>>> compatibility... Because if Maven forces me to jump through those >>>> hoops... >>>> Congratulations, Maven is now an a-hole too. >>>> >>>> >>>> -- >>>> >>>>> Regards, >>>>> Igor >>>>> >>>>> On 2014-06-19, 11:50, Stephen Connolly wrote: >>>>> >>>>> If backwards compatible interoperability is not a requirement then: >>>>> >>>>>> >>>>>> If I upgrade one module in my multi-module build to Maven 5.1 then I >>>>>> am >>>>>> forced right then and there to either: >>>>>> >>>>>> * upgrade all of them to Maven 5.1; or >>>>>> * remove the module from my multi-module build >>>>>> >>>>>> Neither of these are a good user experience in my mind. Maven 5.1 >>>>>> should >>>>>> be >>>>>> able to build a Maven [2.0,5.1] project without modifying the pom... >>>>>> it >>>>>> can >>>>>> do that by loading shim layers on demand if necessary, but to my >>>>>> thinking >>>>>> anything less is going to cause issues for users. >>>>>> >>>>>> >>>>>> So to my thinking we just accept that Maven needs to evolve such that >>>>>> for >>>>>> every version X.Y of Maven you know that you can build a Maven project >>>>>> from >>>>>> the range [2.0,X.Y]. >>>>>> >>>>>> If you have a project that has a parent, then the parent must be in a >>>>>> pom >>>>>> format that buildable by Maven [2.0,${project.prerequisites.maven}], >>>>>> so a >>>>>> child pom requiring Maven 5.1 to build can have a parent pom that >>>>>> requires >>>>>> Maven 5.0 to build but not a parent pom requiring Maven 5.2... there >>>>>> may >>>>>> even be turtles all the way down to an ancestor pom that requires >>>>>> Maven >>>>>> [2.0,3.0.3] to build (IIRC after 3.0.3 you get things like wildcards >>>>>> in >>>>>> excludes due to aether injecting "bonus" functionality... that should >>>>>> have >>>>>> been a modelVersion bump in the strictest sense... but well it wasn't) >>>>>> >>>>>> I also think people overestimate how difficult it is to maintain >>>>>> backwards >>>>>> compatibility. >>>>>> >>>>>> I have a Jenkins plugin that was written against Hudson 1.96 and I can >>>>>> take >>>>>> that .hpi file and drop it into Jenkins 1.568 and it still works >>>>>> unmodified. Similarly I can upgrade a Jenkins installation jumping >>>>>> quite a >>>>>> large number of versions without issue. >>>>>> >>>>>> It is possible to evolve and maintain the ability to read older >>>>>> data... >>>>>> is >>>>>> it easy? well it's not trivial, but it is a disservice to our users if >>>>>> we >>>>>> don't try >>>>>> >>>>>> >>>>>> On 19 June 2014 16:24, Paul Benedict <[email protected]> wrote: >>>>>> >>>>>> I am curious why you interoperability as a requirement? Perhaps >>>>>> >>>>>> questioning >>>>>>> that may seem outrageous, but I see no problem with saying that you >>>>>>> need >>>>>>> to >>>>>>> upgrade to Maven X.Y to read newer POM formats. If a vendor wants to >>>>>>> backport their project into older POM formats, that should be the >>>>>>> vendor's >>>>>>> shoulders and not be a concern of Maven core. If Maven does publish >>>>>>> older >>>>>>> formats of POMs, you then have to decide how many older formats do >>>>>>> you >>>>>>> want >>>>>>> to publish? One day there will be a 4.1 or 5.0, and it's going to >>>>>>> complicate the world if Maven takes on the burden of >>>>>>> interoperability. >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> Paul >>>>>>> >>>>>>> >>>>>>> On Thu, Jun 19, 2014 at 9:57 AM, Stephen Connolly < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>> On 19 June 2014 15:48, Igor Fedorenko <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2014-06-19, 10:30, Stephen Connolly wrote: >>>>>>>>> >>>>>>>>> - Igor is*mostly* right in that we should not deploy the pom >>>>>>>>> that >>>>>>>>> is >>>>>>>>> >>>>>>>>> >>>>>>>>>> used >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> to build to the repository... >>>>>>>>> >>>>>>>>>> - Where Igor is wrong is that for <packaging>pom</packaging> we >>>>>>>>>> should >>>>>>>>>> actually deploy the build time pom to the repository... probably >>>>>>>>>> with >>>>>>>>>> >>>>>>>>>> the >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> classifier `build`... this is safe as `pom` does cannot have a >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> classifier >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> in model version 4.0.0. >>>>>>>> >>>>>>>>> >>>>>>>>> - You couple that with a simple and obvious restriction... your >>>>>>>>>> parent >>>>>>>>>> must >>>>>>>>>> be the same or earlier version of Maven. You cannot have as a >>>>>>>>>> parent a >>>>>>>>>> newer version of Maven than the child is built with. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I think there is more to this. >>>>>>>>>> >>>>>>>>> >>>>>>>>> At very least we need to decide what to do with <parent> in 4.0.0 >>>>>>>>> compatible poms. Maybe we should always deploy effective pom with >>>>>>>>> build-related elements removed. >>>>>>>>> >>>>>>>>> >>>>>>>>> Well I think the simple thing is that the 4.0.0 pom is fully >>>>>>>>> >>>>>>>> resolved >>>>>>>> >>>>>>>> when >>>>>>>> >>>>>>> >>>>>>> you have a builder pom >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I am also not sure if it is enough to deploy "build" parent poms >>>>>>>> as >>>>>>>> >>>>>>>>> is. >>>>>>>>> Your suggested "parent must be the same or earlier version of >>>>>>>>> Maven" >>>>>>>>> implies new versions of Maven can read older pom formats, which I >>>>>>>>> think >>>>>>>>> will significantly limit our flexibility to evolve pom format. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> They need to be able to parse it into the model. Perhaps they do the >>>>>>>> parsing by downloading a parser. But I think it is reasonable to >>>>>>>> expect >>>>>>>> that we can convert older build pom formats into newer ones and just >>>>>>>> let >>>>>>>> Maven take care of it... if we cannot do that then we are really >>>>>>>> >>>>>>>> creating a >>>>>>>> >>>>>>> >>>>>>> brand new build tool rather than evolving Maven >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I wonder >>>>>>>> >>>>>>>> if we can have different solution for force parent poms, like >>>>>>>>> org.apache:apache, which are used by multiple projects and >>>>>>>>> different >>>>>>>>> versions of maven and project-specific parent poms, where it is >>>>>>>>> much >>>>>>>>> easier to require specific version of maven. >>>>>>>>> >>>>>>>>> >>>>>>>>> Well the simple way is we have deployed the 4.0.0 parent pom as >>>>>>>>> >>>>>>>> org.apache:apache:14:pom if you want to upgrade your parent to >>>>>>>> org.apache:apache:15 then you will need to require Maven 4.0+ to >>>>>>>> build. >>>>>>>> >>>>>>>> If >>>>>>>> >>>>>>> >>>>>>> you don't want to upgrade your build time requirements, then don't >>>>>>> >>>>>>>> >>>>>>>> upgrade >>>>>>>> >>>>>>> >>>>>>> the parent... and if we need to "fix" things in the parent for >>>>>>> 4.0.0 >>>>>>> >>>>>>>> consumers, we can always deploy org.apache:apache:14.1 as a newer >>>>>>>> 4.0.0 >>>>>>>> model pom >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Regards, >>>>>>>>> Igor >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------------------------------------ >>>>>>>>> --------- >>>>>>>>> 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] > >
