Hello, Thanks for all the package naming comments.
Package naming is a somewhat difficult task for a project. We stick by the same format used by the kernel and most (well at least "many") other open source projects, where odd second digit (5.1.10) indicates a development version and even second digit (5.2.1) represents a production released version. Doing beta releases or release candidates (rc1, rc2...) is a bit problematic as using extra . (dots), dashes, or underscores (5.1.10.rc1) is not generally acceptable. So we simply glue the rc1 onto the end of the version. If I read the Fedora packaging solution, this seems to work quite well for them. If someone is an expert of all the naming conventions (including Mac, Solaris, ...) and not just an rpm expert, then we are open to suggestions since for us (developers) it is rather trivial to put almost any string. I am not too enthused by the idea of reserving specific ranges of the "patch" (3rd digit) for beta or release candidates as this is too hard for me to remember. Even the odd even distinction we use for the development production releases respectively is generally not known by everyone (see one previous comment) -- it is clearly documented in the manual though. So, if someone can give us a better definitive good clear way to distinguish betas and release candidates (as we currently have in my opinion) that is "portable" we are open. Best regards, Kern On 10/15/2011 12:31 PM, Laurent Papier wrote: > On Fri, 14 Oct 2011 14:54:44 +0200 > Bruno Friedmann<br...@ioda-net.ch> wrote: > >> Dear Developers >> >> This proposal doesn't have to by applied now, so it's mainly a reflection >> for the next run >> 5.3dev 5.4x >> >> Most of the package system (rpm / apt) and associated tools doesn't play >> well with beta rc string in number >> making it always complicated for no good reasons 5.2.0rc2 is> than 5.2.0 >> (work if we start at 5.2.1) > Hi, > Fedora have a detailed solution for this problem > (http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Release_Tag). Maybe > it is specific to rpm package but the solution is easy to use and provide a > smooth upgrade path from rc release to stable release. > > For example, my personal package for 5.2.0rc1 is bacula-5.2.0-0.1.rc1.fc14. > 0.1.rc1.fc14 is the release tag. The 5.2.0 stable release will have a 1.fc4 > tag which is greater than 0.1.rc1.fc4. > > Any debian/ubuntu packager guru here ? > >> On what I see, most big project now use this numbering politics >> alpha stage start with 5.1.6x to 5.1.79 >> beta are mostly in the range 5.1.80 to 5.1.89 >> rc are in 5.1.90 - 5.1.99 > Because there is not a single rule for every project all around the net, I > personally found this a little bit confusing. > If you are very familiar with the project how to you know that > bacula-5.1.64-1.rpm is an alpha release and bacula-5.1.38-3.rpm is a stable > one ? > ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
