The Maven groupId is an important attribute in dependency management, and changing it causes technical problems for the users, as Maven doesn't know the concept of groupId renames/aliases. What happens again and again in real world projects (where a dependency graph of over 100 jar-s is common) is that something depends on original.group.name:foo:1.1.0, and then some other thing on changed.group.name:foo:1.2.0, and because Maven doesn't see this as two conflicting dependencies, both jar will be part of your deployment. Then if the classes from which version will take precedence during class loading can be quite unpredictable (though experience shows that the intended version will take precedence during development and testing, and the legacy version on the production server ;-) ). After you realize what's going on, you can go an manually exclude the 1.1.0 from some 3rd party dependency, but for some it takes time to realize, or can even remain unnoticed for long time, etc.
So changing the groupId can cause some trouble even for projects that start their life in the incubator and has not widely used when they graduate and so had to change groupId. But it's much more problematic for projects that already have established user base before starting incubation (as in this case). The less often you have to change groupId, the better. Wednesday, December 28, 2016, 3:18:52 AM, Christopher wrote: > I think it could also be confusing for users of the Maven version didn't > match the IPMC released version identifier. > > If anything, it probably makes more sense to have the '-incubating' in the > groupId , since it's the endorsement of the foundation which is in the > interim state. The groupId typically contains the TLP name, which would be > incubator. So, org.apache.incubator? I would like that along with dropping > the incubating suffix on all artifact versions (Maven or not). > > I think it's generally confusing for users to have the suffix present, and > redundant when the artifact readme, pom metadata, or other files explain > it's status more clearly. It also creates excessively long file names and > the naming convention conflicts with other post-version identifiers, such > as Maven classifiers and RPM release/arch info. > > On Tue, Dec 27, 2016, 20:18 Daniel Dekany <ddek...@freemail.hu> wrote: > >> Hello, >> >> The last release of Apache FreeMarker (incubating) has these Maven >> coordinates: >> >> <groupId>org.freemarker</groupId> >> <artifactId>freemarker</artifactId> >> <version>2.3.25-incubating</version> >> >> The "-incubating" in the Maven version is confusing for the users, as >> it looks as the version number of an unstable release, and it seems >> that this causes many to stick to the last non-Apache release from 1.5 >> years ago. (See the "*" footnote if you want some more details.) >> >> As far as I know there's no explicit requirement for having >> "incubating" in the Maven artifact version number. So, I wonder, can >> we just omit "-incubating" from the Maven artifact versions from now >> on? In FreeMarker's case the Maven groupId doesn't contain org.apache >> (I know, it should, but that's a different topic), so I guess there's >> less danger of branding confusion here. Of course, the version number >> would remain x.x.x-incubating in the file names of the releases >> downloadable from apache.org and so on. Also, in case it bothers >> anyone, the "name" element in the Maven POM could be changed from >> "Apache FreeMarker" to "Apache FreeMarker (incubating)" (or just to >> "FreeMarker"). >> >> *: For those not working in the Java ecosystem, know that many users >> will not go to the project home page nowadays to find the latest >> version, just look at the versions at the Maven Central. Without >> any place for explanation, "2.3.25-incubating" and such are often >> believed to be development versions. (I have seen a few user >> queries that indicated that too.) It certainly doesn't help either >> that http://mvnrepository.com automatically marks these incubating >> versions with red (~ alpha). Also, on the same place the last >> non-Apache release has almost 5x more usages than the last two >> "-incubating" releases together, which is suspicious. Spring has >> also stuck at that version for some reason. >> >> -- >> Thanks, >> Daniel Dekany >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> -- Thanks, Daniel Dekany --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org