Package naming conventions

Lists: pgadmin-hackers
From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: <pgadmin-hackers(at)postgresql(dot)org>
Subject: Package naming conventions
Date: 2003-08-08 09:40:00
Message-ID: 03AF4E498C591348A42FC93DEA9661B83AF1BF@mail.vale-housing.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgadmin-hackers

Hi Guys,

I have corrected the naming on some of the uploaded beta releases as
they were inconsistant. For reference, let's try to use something like:

Snapshots
=========

pgadmin3-yyyymmdd.tgz
pgadmin3-yyyymmdd.txt
pgadmin3-yyyymmdd.tar.gz
pgadmin3-yyyymmdd.i386.rpm

Releases
========

pgadmin3-x.y.z.tgz
pgadmin3-x.y.z.txt
pgadmin3-x.y.z.tar.gz
pgadmin3-x.y.z.i386.rpm

Of course, local conventions may dictate slightly different formats, but
for anything other than snapshots, let's keep to the version number in
the filename.

Cheers, Dave.


From: Jean-Michel POURE <jm(dot)poure(at)freesurf(dot)fr>
To: Raphaël Enrici <blacknoz(at)club-internet(dot)fr>, Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
Cc: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Package naming conventions
Date: 2003-08-08 13:50:47
Message-ID: 200308081550.47551.jm.poure@freesurf.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgadmin-hackers

Dear all,

I agree with Raphaël. We cannot have two naming conventions for technical
reasons. It is not possible to change the version of an RPM at file system
level. Furthermore, users should be able to install from snapshots, then
upgrade with beta, then install snapshots, etc...

Cheers,
Jean-Michel

On Friday 08 August 2003 15:52, Raphaël Enrici wrote:
> I Totally agree with Dave. But don't you think we could go further ? As
> you just renamed files, the informations concerning the packages are
> still what they were when it was released :
> for example :
> rpm -qpi pgadmin3-0.9.0.i586.rpm
> Name : pgadmin3 Relocations: (not relocateable)
> Version : 0.9 Vendor: (none)
> Release : 20030806 Build Date: Wed Aug 6
> 18:28:01 2003Install date: (not installed) Build Host:
> mandrake.translationforge.com
>
> So, this is still pgadmin3 version 0.9 release 20030806 which is the
> same versionning scheme as snapshots releases (I took a rpm because I
> don't know anything about slackware and freebsd packages). Shouldn't the
> packages be built again with right versions ? IMHO it's not really
> important for beta releases but why not trying to do now what we will
> have to do for the final release ? By this way, we will ask us the good
> questions now and not for final release.
>
> Just for information and critics from you friends, here is what I did
> for Debian packages (and which may be used for other packaging system),
> I'm REALLY open to any corrections concerning this :
> - snapshots releases are versionned like this :
> pgadmin3-x.y.z-0.m+cvsYYYYMMDD-n whith x.y.z equal to pgadmin3 version,
> m and n minor releases number concerning the package itself.
> - beta and future stable releases are versionned like this :
> pgadmin3-x.y.z-0.m
> The "0" in the package release part is imposed by the fact that these
> packages are not official debian one and will become "1" and further
> when integrated in Debian (Think it's a good thing that could be adopted
> by other packagers ?)
> Note that I think that the beta and future stable package releases will
> live their own life (corrections, etc...) independently from snapshots
> releases (I mean in a package point of view).


From: Raphaël Enrici <blacknoz(at)club-internet(dot)fr>
To: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
Cc: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Package naming conventions
Date: 2003-08-08 13:52:39
Message-ID: 3F33AB27.4020007@club-internet.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgadmin-hackers

Dave Page wrote:

>Hi Guys,
>I have corrected the naming on some of the uploaded beta releases as
>they were inconsistant. For reference, let's try to use something like:
>
> Snapshots

>=========
>pgadmin3-yyyymmdd.tgz
>pgadmin3-yyyymmdd.txt
>pgadmin3-yyyymmdd.tar.gz
>pgadmin3-yyyymmdd.i386.rpm
>
>Releases
>========
>pgadmin3-x.y.z.tgz
>pgadmin3-x.y.z.txt
>pgadmin3-x.y.z.tar.gz
>pgadmin3-x.y.z.i386.rpm
>Of course, local conventions may dictate slightly different formats, but
>for anything other than snapshots, let's keep to the version number in
>the filename.
>
>
Dear all,

I Totally agree with Dave. But don't you think we could go further ? As
you just renamed files, the informations concerning the packages are
still what they were when it was released :
for example :
rpm -qpi pgadmin3-0.9.0.i586.rpm
Name : pgadmin3 Relocations: (not relocateable)
Version : 0.9 Vendor: (none)
Release : 20030806 Build Date: Wed Aug 6
18:28:01 2003Install date: (not installed) Build Host:
mandrake.translationforge.com

So, this is still pgadmin3 version 0.9 release 20030806 which is the
same versionning scheme as snapshots releases (I took a rpm because I
don't know anything about slackware and freebsd packages). Shouldn't the
packages be built again with right versions ? IMHO it's not really
important for beta releases but why not trying to do now what we will
have to do for the final release ? By this way, we will ask us the good
questions now and not for final release.

Just for information and critics from you friends, here is what I did
for Debian packages (and which may be used for other packaging system),
I'm REALLY open to any corrections concerning this :
- snapshots releases are versionned like this :
pgadmin3-x.y.z-0.m+cvsYYYYMMDD-n whith x.y.z equal to pgadmin3 version,
m and n minor releases number concerning the package itself.
- beta and future stable releases are versionned like this :
pgadmin3-x.y.z-0.m
The "0" in the package release part is imposed by the fact that these
packages are not official debian one and will become "1" and further
when integrated in Debian (Think it's a good thing that could be adopted
by other packagers ?)
Note that I think that the beta and future stable package releases will
live their own life (corrections, etc...) independently from snapshots
releases (I mean in a package point of view).

Regards,

Raphaël