search

adrianlopezroche / fdupes

FDUPES is a program for identifying or deleting duplicate files residing within specified directories.
2.46k stars 187 forks source link

release 1.51 is bigger than 1.6.0 #65

Closed sergiomb2 closed 7 years ago

sergiomb2 commented 7 years ago

Our release-monitoring is right [1] from 1.51 you can't change to 1.6 , or form 1.40 to 1.6.0 , maybe release 1.60.0 ?

[1] https://release-monitoring.org/project/786/

sandrotosi commented 7 years ago

this has already been discussed: https://github.com/adrianlopezroche/fdupes/issues/63#issuecomment-243094218

sergiomb2 commented 7 years ago

I mean the release , the release version can't be 1.6 since 6 is not bigger than 50 .

sandrotosi commented 7 years ago

well, it can, and it's not like the first time it happened in the sw release history. Adrian already explained (in the comment i linked before, the X.Y.Z format is the new schema and X.YY will not be used anymore) just fix your monitoring tool to accommodate it

sergiomb2 commented 7 years ago

Well , will give work to all distros etc etc

sandrotosi commented 7 years ago

a new release already gives work to all distros... you can nitpick on the version or accept that a new release is always a great thing (in particular for fdupes) and just deal with the situation and move on

sergiomb2 commented 7 years ago

https://rpmfind.net/linux/rpm2html/search.php?query=fdupes no much distros, but ok , or we just change now , or is too late .

Thanks for your time , anyway I think we should educate upstream :smiley:

adrianlopezroche commented 7 years ago

Looking at the list of packages at release-monitoring where this has happened, perhaps the problem lies with the service's assumptions about versioning?

[1] https://release-monitoring.org/projects/updates/odd

On Tue, Sep 20, 2016, 3:39 AM Sérgio Basto notifications@github.com wrote:

Our release-monitoring is right [1] from 1.51 you can't change to 1.6 , or form 1.40 to 1.6.0 , maybe release 1.60.0 ?

[1] https://release-monitoring.org/project/786/

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/adrianlopezroche/fdupes/issues/65, or mute the thread https://github.com/notifications/unsubscribe-auth/AF8J_UmFsg9U6BpGtf6U_7GwvCe64HtFks5qr42VgaJpZM4KBUD7 .

adrianlopezroche commented 7 years ago

It would be 1.10.0 (as is the usual practice when using this format) which in the old scheme would have been 1.100. I'll probably end up releasing the upcoming ncurses-capable version (release date undetermined) as 2.0.0.

On Tue, Sep 20, 2016, 11:23 AM Jody Bruchon notifications@github.com wrote:

Making 1.51 sort lower than 1.6.0 is certainly a pain though. What happens to the sort of choice when it reaches 1.10.0? Will it read as 1.1.0.0 and sort 1.10.0 below 1.6.0? shrug I would have just opted for a 2.0 release to avoid problems and whatever big feature was planned to trigger a 2.0 release could be a 3.0 release.

Anyway, it's done now, so there is no sense in complaining about it, and as long as it doesn't become 1.10* anywhere along the way, an exception is easy enough to implement.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/adrianlopezroche/fdupes/issues/65#issuecomment-248335341, or mute the thread https://github.com/notifications/unsubscribe-auth/AF8J_UwBnNArTJHUnHNx5ODvH-f4v62nks5qr_pqgaJpZM4KBUD7 .

sergiomb2 commented 7 years ago

We can (like Debian did) use epoch , so we bump epoch and 0:1.51 < 1:1.6 , and I have to ask to admin on release monitoring to clear history of fdupes and another minor problems that other distros can have like fail to detect a new version. Do 2.0 for me is a good alternative , change numeration not always means big changes in code, you got example of kernel .

Now I'd like to know if you going to fix this issue or not ? to processed , no rush . Thanks.

adrianlopezroche commented 7 years ago

I'm going to stick to the X.Y.Z convention from now on. The ncurses interface looks like a good excuse to bump up the major version number when that is released, but in the meantime I'll go on using major version 1 so it's probably best for you to update the epoch.

On Tue, Sep 20, 2016, 2:17 PM Sérgio Basto notifications@github.com wrote:

We can (like Debian did) use epoch , so we bump epoch and 0:1.51 < 1:1.6 , and I have to ask to admin on release monitoring to clear history of fdupes and another minor problems that other distros can have like fail to detect a new version. Do 2.0 for me is a good alternative , change numeration not always means big changes in code, you got example of kernel .

Now I'd like to know if you going to fix this issue or not ? to processed , no rush . Thanks.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/adrianlopezroche/fdupes/issues/65#issuecomment-248386508, or mute the thread https://github.com/notifications/unsubscribe-auth/AF8J_b1wWPIFrZlvoWGhACmKv2_1AgeXks5qsCM-gaJpZM4KBUD7 .

sergiomb2 commented 7 years ago

I give up