[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#516351: see/seetxt 0.61



On Mon, 2009-07-13 at 09:53:42 -0400, MK wrote:
> > I've noticed you are managing the version number as if it was a 
> > float.
> 
> Yeah, I was not aware of this issue at all.  It's all the same to me, 
> so I could make the next one 0.6.2, or else 0.70.

Given that there's already a release out there with 0.60, I guess the
safest would be to use 0.70, and just take into account the versioning
rules for the future.

> I thought the debian package was going to be called seetxt, you may 
> have to bug Joop about that as I did not do the packaging.

Ah, the binary package is named seetxt, it was just the source package
which is called see, I guess to match with the upstream source
tarballs. Changing the source package after the fact should be no
problem at all, and it should not require any action from the
ftp-masters.

> As for the project name and source tarballs, I can do that easily 
> enough as well -- the homepage is actually already called 
> seetxt.sourceforge.net since there was the same conflict there 
> initially.  So that will mean updating a few things at the website, I 
> should be able to do that this week.  I guess I will either have to 
> actually tar another release, or else add some note to the effect that 
> "seetxt 0.6.1" is the same as the previously released "see 0.61".

Yeah, I guess a new release would leave things more clear (for other
distros as well). The problem with the version is that as the binary
package is 0.60 already, then even if the source package gets renamed
the binary will get the same version, and thus switching upstream to
seetxt-0.6.1 would make the version go backwards anyway, and require
an epoch.

> Not sure what this will mean for the listing here:
> http://ftp-master.debian.org/new.html
> Will we have to start all over again now?  Or can it get accepted as 
> "unstable" and then we can make minor adjustments?

That should not be a problem, renaming the source package afterwards does
not imply major work, just few strings changed here and there.

thanks,
guillem



Reply to: