search

getredash / redash-toolbelt

API client and utilities to manage a Redash instance
BSD 2-Clause "Simplified" License
140 stars 74 forks source link

Bump to 0.1.7 ahead of forthcoming release #85

Closed susodapop closed 3 years ago

susodapop commented 3 years ago

0.1.6 is already released. The repo should stay ahead of the current released version so it's clear that master and the release differ.

justinclift commented 3 years ago

Good idea. :smile:

justinclift commented 3 years ago

Ahhh, I don't have write access to this repo, so my review approval isn't really doing anything. :wink:

At least 1 approving review is required by reviewers with *write* access.
justinclift commented 3 years ago

Actually, thinking about this with a bit more coffee in me first... perhaps bumping to .7 isn't the right approach. How about bumping it to (say) .99 instead, so the dev version is at a recognisable number that's much higher than the real releases are likely to be?

susodapop commented 3 years ago

@justinclift

Ahhh, I don't have write access to this repo, so my review approval isn't really doing anything.

That's actually fine. I just didn't want to merge late at night without someone else gut-checking me 😉

perhaps bumping to .7 isn't the right approach. How about bumping it to (say) .99 instead, so the dev version is at a recognisable number that's much higher than the real releases are likely to be?

The way we version Redash is to have the version on master to always be the next released version. I'm doing the same with toolbelt. Are there other projects that version with .99 or similar?

susodapop commented 3 years ago

I'm moving forward with 0.7 for now but we can reconsider if this is the correct versioning approach going forward.

justinclift commented 3 years ago

Are there other projects that version with .99 or similar?

Yeah, we take that approach with "DB Browser for SQLite", but the use case is pretty different. :wink:

With that software, we create branches for each main release (eg v3.12.x) and have the master branch be "development only". Having master use a version number like 3.12.99 lets us see from bug reports that it was built from a dev codebase rather than a release. It works decently well for that scenario. :smile: