[pkg-fso-maint] Anyone working on packaging libeflvala (EFL Vala Bindings)? Or should I attempt to do so?

Jonas Smedegaard dr at jones.dk
Sat May 22 17:26:13 UTC 2010


On Sat, May 22, 2010 at 02:56:21PM +0200, Visti Andresen wrote:
>On Sat, 22 May 2010 13:31:13 +0200
>Sebastian Reichel <elektranox at gmail.com> wrote:
>
>> On Sat, May 22, 2010 at 11:20:58AM +0200, Visti Andresen wrote:

>> > Package version number?
>> > -----------------------
>> > Any preferences/best practice hints?
>>
>> fso-frameworkd has real versions (which is the 0.9.5.9 part), but we 
>> switch to revisions between two version, thus the +git20100131 part.
>>
>>
>> Now that I answered your questions some more comments:
>>
>> You want to package [1] and not the stuff from git.fso.org! Apart
>> from this there is a version number: 0.5.0 (check configure.ac)
>
>As long as I am using a git version i suppose that I should suffix the
>0.5.0 with a .something and the git revision?
>(As there might be more than one git revision with the same
>version.major.minor number)

If the code hints that it is somewhere around 0.5.0 but upstream did not 
actually release any tarballs using that version number, then I would 
suggest to instead of "+" use "~" as delimiter, so as to make room for a 
potential later official release (without adding an epoch).

Above is mentioned to use the "git revision". Unlike Subversion, Git 
uses a hash as "revision", and I would recommend against using That. 
Instead use the date of the git snapshot, as that is certain to be 
sequential (if you would ever need two releases on same day it is easy 
to suffix a .1).

So either 0.5.0~0+git20100131 (if no official upstream 0.5.0 release) or 
0.5.0+0+git20100131 (if known to be beyond[1] a 0.5.0 release).


Hope that makes sense.


  - Jonas

[1] Beware that it can be risky to package bleeding edge code: You might 
end up promoting code that upstream deliberately did not want released 
yet, which might turn out not to be the direction that upstream decided 
to officially release later on, and potentially - due to the wide 
exposure of Debian packages - make life difficult for upstream.

It is thus a good idea to keep in touch with upstream and try make clear 
such "sneak previous" with them.  It is not mandated by FLOSS licensing, 
but wise for the social dynamics within the wider ecosystem on FLOSS :-)

-- 
  * Jonas Smedegaard - idealist & Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-fso-maint/attachments/20100522/69cc5797/attachment.pgp>


More information about the pkg-fso-maint mailing list