On Tuesday 13 of November 2012 21:36:55 Darrell Anderson wrote:
> > One of the points for discussion in R14 Road Map is the question about
> > naming packages. I suppose it is beyond dispute that in the name of
> > packages should be 'trinity' (or perhaps 'tde'?). Other issues for
> > decision I would see the following:
> >
> > 1. 'trinity' before name or after? Or leave it distribution specific?
> >
> > 2. How to mark development version of packages? What about 14.0.0~preXXX?
> > For example: + amarok-trinity_14.0.0~pre148.orig.tar.xz
> >
> > amarok-trinity_14.0.0~pre148-0debian11+pr16~squeeze...
> > + amarok-trinity-14.0.0~pre148-i486-13.1_1.txz
> >
> > Note0: Because the Debian / Ubuntu version number must begin with a
> > digit, it is impossible packages with the version number beginning with
> > the letter 'R'. Therefore, such a question was unnecessary.
> >
> > Note1: I am aware that it is not currently possible to change the version
> > numbers of packages in nightly-builds. But I want to have arranged rules
> > to marking package versions before beta / RC versions, and before moving
> > nightly-builds to target version 14.1.0.
>
> My thoughts:
>
> 1. Let's agree as a community to insert the "trinity" text string in the
> package name. Whether as a prefix or suffix to the package base name
> probably is not important.
>
> 2. Whether the "R" prefix is used in the version number probably is not
> important. Let distro packaging rules prevail.
>
> 3. I believe the GIT short version is the best way to identify the snapshot
> version. Whether text strings such as "pre" are used probably is not
> important.
>
> Recently I updated my package names to include the "trinity" string to
> avoid potential package name conflicts with KDE4. Currently I have the
> "trinity" string at the beginning of all package names. I could modify that
> to insert the "trinity" string after the base package name.
>
> Because of the different rules for distro package naming, I suspect that
> where the "trinity" string is included in the package name is not as
> important as much that we all include the string.
>
> I prefer the string "trinity" rather than "tde" because for many users who
> use package managers to search for packages, "trinity" is more descriptive
> than "tde."
>
> Regarding development packages I have been pulling the GIT short version
> and using that number as part of the package names:
>
> GIT_VERSION="`git shortlog . | grep -E '^[ ]+\w+' | wc -l`"
>
> I build package sets for different Slackware releases. I use the Slackware
> release number and either "32" or "64" to note CPU architecture. I haven't
> been using other strings such as "pre," but I see no reason why others
> can't do that if they want. I include R14.0.0 in the package name although
> some people might argue I should be using "3.5.13." But the next release is
> forking version numbers and we have no easy way to show that the
> development packages are 3.5.13.90 or something similar as with other
> projects. Thus I stick with R14.0.0 for now.
>
> Whether all of us agree to use "R" in the version number probably is not
> important. If distro packaging rules require not using then do that and if
> there are no such rules with other distros then let the packager decide. I
> prefer using the "R" prefix because the current Slackware release is 14.0
> and the "R" prefix helps distinguish the two numbers. :)
>
> Just my initial thoughts on the topic. :)
>
> This topic is important. If we agree now on a very basic naming scheme then
> we all have plenty of time to adjust our build scripts before we begin to
> approach any soft freeze. Better now to do that work than scramble like
> Keystone Kops when we approach the release date. :)
>
> Darrell
>
>

I also prefer the 'trinity' prior to 'tde'. Although it is longer, it is 
better distinguishable from 'kde'. Since it is used for 'deb' packages as 
well as the 'rpm' packages, for 'trinity' are apparently consensus. The 
question remains whether we want to seek consensus also for the location? 
Before × after × it does not matter?

Using git hash in version numbers has one major drawback - git hash is not 
growing number == without additional informations cannot be used to 
distinguish the "earlier × newer" version => for ensuring updates to a newer 
version. Use git hash is certainly a good idea, but there remains a need for 
an growing pre-releases number. Here we can see a similar way used in the 
linux kernel - version number for new relase are combined with 'rc' number. 
What then combine both - pre-release (growing) version number and also git 
hash? The problem is that it will be long :)

For example:
+ amarok-trinity_14.0.0~pre148+d2812a09.orig.tar.xz
  amarok-trinity_14.0.0~pre148+d2812a09-0debian11+pr16~squeeze

Slavek
--