+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
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] > > -- Sent from my phone
