latest package deb/rpm package is still pointing to 0.9.0 version

[dgolja]

Hello,

I just noticed that the latest package is still pointing to 0.9.0 influxdb version. For example http://influxdb.s3.amazonaws.com/influxdb_latest_amd64.deb is 0.9.0, instead of 0.9.2.1.

Please update this reference, because for automation tools this link is really handy, until you guys have a proper apt/yum repository.

[beckettsean]

That "latest" link is a leftover from a prior build strategy. We've left it up precisely because some automated scripts expect it but it does not update with new releases. It always points to the same 0.9.0 version.

Since 0.9.1 all official releases are explicitly tagged, e.g. https://s3.amazonaws.com/influxdb/influxdb_0.9.2_amd64.deb, and all nightly releases are tagged with "nightly", e.g. https://s3.amazonaws.com/influxdb/influxdb_nightly_amd64.deb.

See https://influxdb.com/download/index.html for more information.

[beckettsean]

@pauldix @toddboom maybe we should kill the old "latest" links since we're far enough away from 0.9.0 that few people are still using it? Seems like it's just a source of confusion, now.

[dgolja]

Hmmm I guess it's a matter of opinion, but not having an proper repository (apt/yum) makes automation tool such as puppet, chef, ansible, etc hard to deal with the installation of the latest package. In practice that mean in Puppet I will need to update the module whenever there is a new influxdb release, to make sure that by default it will install the latest version.

Also still keeping the latest package link alive and not update it to the last stable release just add more confusion, because it's deceiving. Basically "old" users will except to get the last version, but they will not.

Last but not least, why than you have the nightly build link, if you deprecated the same logic for the last stable release ?

If I could decide I would keep the latest link alive until you switch to a proper deb/apt repository. At the end of the day more you make influxdb friendly to automation tool, more people will use it :)

[beckettsean]

Hmmm I guess it's a matter of opinion, but not having an proper repository (apt/yum) makes automation tool such as puppet, chef, ansible, etc hard to deal with the installation of the latest package. In practice that mean in Puppet I will need to update the module whenever there is a new influxdb release, to make sure that by default it will install the latest version.

Yes, this is very true, and very intentional. There are significant enough changes between the 0.9 versions that auto-installing the latest is not a good idea yet. Some releases even have breaking changes, although minor. Rather than have people surprised when new boxes don't work as expected we are requiring automated scripts to pick a particular version. Updating a version string isn't a very painful workaround for now.

Also still keeping the latest package link alive and not update it to the last stable release just add more confusion, because it's deceiving. Basically "old" users will except to get the last version, but they will not.

See my note just above yours. We left it running when it was deprecated, because some people did depend on it. There was an announcement to the mailing list about the change. Now that it's been deprecated for months it's probably time to retire it. Thanks for the reminder!

Last but not least, why than you have the nightly build link, if you deprecated the same logic for the last stable release

Because nightly builds are known unstable builds. If you want to link to that for your automated scripts presumably you know the pain you are inviting. This is a very common pattern and I don't see it as inconsistent to have explicitly declared official releases and automatically updated nightly builds.

If I could decide I would keep the latest link alive until you switch to a proper deb/apt repository. At the end of the day more you make influxdb friendly to automation tool, more people will use it :)

Totally agreed and understood. Right now we're still working out basic performance and functionality for clustering. This isn't the end of the journey and we have plans for distro-specific packages that work for each style, but we have to prioritize everything. Since there's a reasonable workaround we are delaying more work on full automation. You should see much better support for that once the clustering releases are finished (post 0.9.5 or thereabouts)

[dgolja]

Ok fair enough, so until influxdb 1.0.0 I guess there is no other way around.

Btw however I still thought that this project is using semantic version, so worst case scenario even if you install a newer version of influxdb from 0.9.X branch with an older config file also from 0.9.X branch it will still work, but some feature will miss ?

[beckettsean]

even if you install a newer version of influxdb from 0.9.X branch with an older config file also from 0.9.X branch it will still work, but some feature will miss ?

Sadly that's not quite true. #3345 and #3526 mean that the point releases aren't quite drop in replacements. They are close, but not quite.

[dgolja]

True, but from the installation/config point of view this are non breaking changes 🙈