First of all, just to restate the intent: I don't suggest renaming the Jira versions because of the tool limitations. I think it makes sense to use something that is aligned with the module name and that problem was exposed by the tooling.
We created Jira versions in the form of 'Artifact Name' 'Version' for quite some time, only one of them stands out by being different. Just a note, not something bad by itself. On the idea that artifact names are opaque to our users, I think we're focusing too much on the slingfeature-maven-plugin vs 'OSGi Feature Maven Plugin' discussion. In this particular instance I think the artifact name is wrong. It should be 'SlingFeature Maven Plugin', which would make it obvious for users what version to report bugs against. In my mind the rule that Georg proposed is basically how we generate artifact names, e.g. - org.apache.sling.jcr.base -> 'JCR Base' - org.apache.sling.api -> 'API' etc I personally am not proposing a big change where we rename historically released versions, I am not sure if it is helpful and if it justifies the effort. I would however suggest that we at least keep the 'name' 'version' convention, e.g. 'slingfeature-maven-plugin 1.4.0' instead of 'slingfeature-maven-plugin-1.4.0' format, as it nicely separates the artifact from the version itself. Thanks, Robert On Wed, 2020-09-23 at 10:22 +0200, Georg Henzler wrote: > Generally I'm also in favor of the artifactId because it > makes a proper id (as already stated). However it is a lot > of noise because all versions in JIRA project "SLING" will > start with "org.apache.sling.". So why not just use the > rule > > substringAfter(artifactId, "org.apache.sling.") + "-" + version > > That would give us versions like api-2.23.0, auth.core-1.5.1 etc. > The big advantage of this is that you see the actual version > number in JIRA UI (if the version string is very long, you only > see the prefix and the actual version is cut off, this really > has to be avoided and hence IMHO we cannot just use the > artifactID) > > We don't need to change the past, we can just use the name > convention for the future for all releases... (and Robert can > fix the tooling to exactly one well-defined release name) > > WDYT? > > -Georg > > > On 2020-09-23 09:52, Carsten Ziegeler wrote: > > Our base rule is that the BSN is the same as the artifact ID. > > There might be some exceptions, sure, but that's probably > > neglectable. > > > > At least I'm not arguing for doing a rename at this point in time - > > but rather keep things just as they are. If someone feels strongely > > to > > rename in Jira, that's fine. > > > > Regards > > Carsten > > > > Am 23.09.2020 um 08:23 schrieb Konrad Windszus: > > > For bundles the artifact id is not that visible but the BSN is. > > > This is not necessarily the same. > > > So if we do a rename in JIRA we should take BSN for bundles and > > > artifact ID for Maven plugins. > > > Konrad > > > > > > > On 23. Sep 2020, at 08:08, David Bosschaert > > > > <[email protected]> wrote: > > > > > > > > +1 to using Artifact IDs in JIRA. As mentioned by others, if > > > > for > > > > example > > > > someone finds a bug running the slingfeature-maven-plugin they > > > > would > > > > probably have a hard time finding the component named 'OSGi > > > > Feature > > > > Maven > > > > Plugin'. To be sure they would have to go to the pom.xml of > > > > the > > > > original > > > > codebase and look for the name tag, which is: > > > > <name>Apache Sling OSGi Feature Maven Plugin</name> > > > > Then they'd have to take off the 'Apache Sling' prefix. > > > > > > > > Another problem is that the name is not required to be unique. > > > > It > > > > _should_ > > > > be, but with the ID you're sure that it's unique. > > > > > > > > My 2c, > > > > > > > > David > > > > > > > > On Wed, 23 Sep 2020 at 06:09, Carsten Ziegeler < > > > > [email protected]> > > > > wrote: > > > > > > > > > Just to state it again, artifact name is really not useful > > > > > for our > > > > > users > > > > > out there trying to file a bug against a module. Artifact id > > > > > is in > > > > > their > > > > > face when they use these things, being it the plugin name, > > > > > the maven > > > > > coordinates or the symbolic name. Everything is based on ids. > > > > > Ids are stable - names might change > > > > > > > > > > Renaming the existing artifact ids in Jira to names, makes it > > > > > worse. > > > > > > > > > > We didn't have any problem with this for years, and I don't > > > > > understand > > > > > why a new tool developed by ourselves should force us now to > > > > > change > > > > > things. Why can't the tool simply look for both, id and name > > > > > - and > > > > > we're > > > > > done with this? > > > > > > > > > > Regards > > > > > Carsten > > > > > > > > > > Am 22.09.2020 um 20:38 schrieb Konrad Windszus: > > > > > > I would also personally prefer artifact id instead of name > > > > > > in JIRA. > > > > > > But > > > > > the majority of version names in JIRA is right now named > > > > > after the > > > > > artifact > > > > > name ( > > > > > https://issues.apache.org/jira/projects/SLING?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=released). > > > > > Also our releases section currently uses artifact names ( > > > > > https://sling.apache.org/releases.html). > > > > > > We should do it consistently and I am not sure it is worth > > > > > > the > > > > > > effort to > > > > > migrate all the release version names (would require some > > > > > scripting). I > > > > > would tend to say, for consistency and simplicity: Just turn > > > > > the few > > > > > which > > > > > use artifact id right now into artifact name > > > > > > Konrad > > > > > > > > > > > > > On 22. Sep 2020, at 18:59, Carsten Ziegeler < > > > > > > > [email protected]> > > > > > wrote: > > > > > > > > > > > > > > I personally think its ok if we use the artifact name in > > > > > > > jira, > > > > > > > like in > > > > > this case - especially as the name might change. Whatever we > > > > > decide, > > > > > it > > > > > needs to be consistent across a module- meaning if we start > > > > > to > > > > > rename with > > > > > version 1.4.0 then we also need to rename all previous > > > > > versions. > > > > > > > > > > > > > > Now from a customer perspective, if someone wants to file > > > > > > > a bug > > > > > > > against > > > > > the slingfeature-maven-plugin (which is what is used and what > > > > > is > > > > > visable in > > > > > the error from maven), I think someone finds > > > > > slingfeature-maven-plugin-1.4.0 much easier than 'OSGi > > > > > Feature Maven > > > > > Plugin > > > > > 1.4.0' which is nowhere visible in maven output. > > > > > > > Regards > > > > > > > Carsten > > > > > > > > > > > > > > Am 22.09.2020 um 17:07 schrieb Robert Munteanu: > > > > > > > > Hi, > > > > > > > > I am in a middle of a release (and using the committer > > > > > > > > cli [1]) > > > > > > > > and I > > > > > > > > got stuck due to an unexpected (for the tool) version: > > > > > > > > java.lang.IllegalArgumentException: No releases > > > > > > > > found in > > > > > > > > 'slingfeature-maven-plugin-1.4.0' > > > > > > > > To go for the quick fix, I renamed that version to > > > > > > > > 'OSGi Feature > > > > > > > > Maven > > > > > > > > Plugin 1.4.0', matching the module name. This is > > > > > > > > quickly > > > > > > > > reversible so > > > > > > > > I just did the change. > > > > > > > > Of course, the tool can be changed, but there is some > > > > > > > > value IMO > > > > > > > > in > > > > > > > > having module names and Jira version names aligned, > > > > > > > > namely: > > > > > > > > - it is clear for users and tools what release maps to > > > > > > > > which > > > > > > > > module > > > > > > > > - we don't have to invent a second name for the same > > > > > > > > thing :-) > > > > > > > > I'm open to saying that version names can be arbitrary, > > > > > > > > but then > > > > > > > > we can > > > > > > > > simplify our life by having matching names. > > > > > > > > Thanks, > > > > > > > > Robert > > > > > > > > [1]: > > > > > > > > https://github.com/apache/sling-org-apache-sling-committer-cli/ > > > > > > > > > > > > > > -- > > > > > > > -- > > > > > > > Carsten Ziegeler > > > > > > > Adobe Research Switzerland > > > > > > > [email protected] > > > > > > > > > > -- > > > > > -- > > > > > Carsten Ziegeler > > > > > Adobe Research Switzerland > > > > > [email protected] > > > > >
