Match package version number to Hugo version number

[jakejarvis]

At first glance browsing npmjs.com I thought this hadn't been updated since Hugo v0.48 — I'm glad I was wrong since this package is incredibly useful, but is there any reason the version numbers for this package can't match the version numbers for the Hugo binary that's downloaded (going forward of course)? Not a huge deal but it might make things more intuitive (and it'd be nice to know which version of Hugo a site is using just by looking at package.json).

Thanks for actually keeping this package up to date, though! 😉

[markgaze]

Agreed, it would be nice to be able to choose the version of Hugo by choosing the matching version of this package.

[TheOddler]

I concur, its very confusing that (hugo-bin) version 0.49.0 is (hugo) version 0.61.0.

[pavelbinar]

Yes, I was about to create a ticket for that but found out that this is actually a common problem.

Please consider aligning the hugo and hugo-bin version.

[XhmikosR]

I wanted to do that, but there's no guarantee the versions will stay in sync. So I left things as they were since the beginning.

/CC @satoshun00

[dkebler]

Make your new commits (don't publish)
npm version <new hugo release version>
npm publish

as long at the version you set with npm version is > the current published version npm publish will work.

this could be part of a bash script that you run. I have one to update hugo(extended) on any linux machine and it checks for updates first and parses the version number that could be used in npm version. Could been done as a 'cron' job that way no one need to manually update this package when hugo binary is updated. Anyway might be of some help/inspiration.

Here is my script
https://gist.github.com/dkebler/1188d098d62166fdc6065fb2658a71dd

another thought
Since the hugo binary is not huge (45mb uncompressed) maybe both could be downloaded together and the default export could be hugo with hugoext being a named export of the extended version. Then users don't have to do all those gyrations with environment or package.json and rerunning install but just import the version they want in their code.

[satoshun00]

Thank you for suggestion.
I commented to same issues before:
#33 (comment)

But it's not make sense to me, because "mirroring Hugo versions" prevents reasonable versioning of hugo-bin itself.
When hugo-bin v0.30.2 ships gohugoio/hugo v0.30.2, and if hugo-bin needs to upgrade some dependencies, hugo-bin cannot increment patch version

[chalin]

I wanted to do that, but there's no guarantee the versions will stay in sync. So I left things as they were since the beginning.

@XhmikosR @satoshun00: you can use version suffixes +1, +2, etc to ensure that you stay in sync with Hugo versions. For example: 0.88.1+1.

/cc @austinlparker @nate-double-u

[XhmikosR]

Sorry, personally I have no interest in this. So, unless it's automated, I will continue using npm version minor or npm version patch.