Re: Jira version names vs Maven module names

[Robert Munteanu <ro...@apache.org>]

On Thu, 2020-09-24 at 12:08 +0200, Carsten Ziegeler wrote:
> THanks Robert,
> 
> now if I get it right you're proposing to change
> 
> 'slingfeature-maven-plugin-1.4.0'
> 
> to
> 
> 'slingfeature-maven-plugin 1.4.0'
> 
> in Jira, correct?
> 
> And revert the renaming to "OSGi Feature Maven Plugin" ?

I've now removed all traces of 'OSGi Feature Maven Plugin' from the
versions and moved to 'slingfeature-maven-plugin XXX' format.

Thanks,
Robert
> 
> I'm fine with that
> 
> Regards
> Carsten
> 
> Am 24.09.2020 um 11:58 schrieb Robert Munteanu:
> > 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
> > > > > > <da...@gmail.com> 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 <
> > > > > > cziegeler@apache.org>
> > > > > > 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 <
> > > > > > > > > cziegeler@apache.org>
> > > > > > > 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
> > > > > > > > > cziegeler@apache.org
> > > > > > > 
> > > > > > > --
> > > > > > > --
> > > > > > > Carsten Ziegeler
> > > > > > > Adobe Research Switzerland
> > > > > > > cziegeler@apache.org
> > > > > > >