`beet version` on version 1.3.19 returns "beets 1.3.18"

[somasis]

somasis@seneca:beets/ (master) % beet version
beets version 1.3.18
plugins: acousticbrainz, bpd, convert, discogs, duplicates, embedart, fetchart, filefilter, follow, fromfilename, ftintitle, fuzzy, importadded, info, lastgenre, lastimport, mbcollection, mbsync, missing, mpdupdat
e, random, replaygain, rewrite, scrub, web

After grepping for '1.3.18' I figured out that beets/__init__.py didn't get updated when 1.3.19 was tagged.

[jackwilsdon]

Oh deary me, that is a bit of a problem! Maybe we can make the change and force update the tag @sampsyo? Has the version been released on any package managers yet?

[jackwilsdon]

Oh deary me, that is a bit of a problem! Maybe we can make the change and force update the tag @sampsyo? Has the version been released on any package managers yet?

[jrobeson]

I'd rather see a .20 release than messing with the tags

[jrobeson]

I'd rather see a .20 release than messing with the tags

[somasis]

I found this while packaging it for Exherbo and I figured I should change the version to be correct, to avoid any confusion if users of the package reported bugs on here. I think a .20 release would be better than a force update as well.

[somasis]

I found this while packaging it for Exherbo and I figured I should change the version to be correct, to avoid any confusion if users of the package reported bugs on here. I think a .20 release would be better than a force update as well.

[sampsyo]

Oh no! We'll have to be more careful in the future; something must have gone wrong with the release script. We will try to get a .20 release out the door as soon as possible to rectify this.

[sampsyo]

Oh no! We'll have to be more careful in the future; something must have gone wrong with the release script. We will try to get a .20 release out the door as soon as possible to rectify this.

[JDLH]

I just discovered this problem also. It slowed me down in diagnosing an issue with beets.

It looks to me also like there was an oversight updating __version__ in beets/__init__.py, during the Version bump: 1.3.19 of commit 2b9f477.

I also think it's worth fixing, but I don't have expertise about which is the best way to fix it.

[JDLH]

I just discovered this problem also. It slowed me down in diagnosing an issue with beets.

It looks to me also like there was an oversight updating __version__ in beets/__init__.py, during the Version bump: 1.3.19 of commit 2b9f477.

I also think it's worth fixing, but I don't have expertise about which is the best way to fix it.

[jrobeson]

@sampsyo is taking care of it for the next version. It'd be nice to have a check in release.py to make sure they match though. Alternatively, we should read beets/__init__.py for the __version__ attribute and populate the version in setup.py that way. I'm not sure why we don't already do that.

[jrobeson]

@sampsyo is taking care of it for the next version. It'd be nice to have a check in release.py to make sure they match though. Alternatively, we should read beets/__init__.py for the __version__ attribute and populate the version in setup.py that way. I'm not sure why we don't already do that.

[sampsyo]

Yeah, I still don't understand why release.py didn't update the version in one location…

[sampsyo]

Yeah, I still don't understand why release.py didn't update the version in one location…

[jrobeson]

@sampsyo : how come we don't just use __version__ in setup.py ?

[jrobeson]

@sampsyo : how come we don't just use __version__ in setup.py ?

[sampsyo]

As in, we'd add an import beets at the top of setup.py? We could do that, but we don't currently have to load or execute any beets code to do a distribution, which is nice. Depending on the right version of the beets package being on sys.path when running setup.py is one more way things could go wrong.

[sampsyo]

As in, we'd add an import beets at the top of setup.py? We could do that, but we don't currently have to load or execute any beets code to do a distribution, which is nice. Depending on the right version of the beets package being on sys.path when running setup.py is one more way things could go wrong.

[jrobeson]

then I guess a check to compare the versions in release.py is the way to go then

EDIT: or a test!

[jrobeson]

then I guess a check to compare the versions in release.py is the way to go then

EDIT: or a test!