-
Notifications
You must be signed in to change notification settings - Fork 811
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Start tagging/versioning updates #10
Comments
If I may, I like the idea of tagging releases. :) p.s. |
Hey, that would be great! We were thinking about having a stable release before we start using tagged releases but I'd like to hear what you have to say about this. Maybe we are wrong :) |
Naturally any version tag should point to a stable release. My humble suggestions are as follows:
|
Thanks for the suggestions! Let me see if I can comment on some of them.
|
Awesome! My idea is to start writing some issues and later assign some of them to a milestone. I'd however only assign an issue to a milestone if someone is going to do it. Regarding tests, I have started working on this other framework and its still very basic but it is the best tool I have seen so far for testing fish scripts. The other frameworks I have seen are super complicated and hard to write/read tests. I'm willing to add tests for the crucial parts of the system as we have almost no tests at the moment. And from now on, focus on releasing features covered by tests only. |
I am not a fan of git-flow. I would rather avoid it and keep it simple:
|
Travis does support running builds on OSX, but we wouldn't be able to use docker for that. 💭 I'm unsure now... perhaps we should lose the benefits of doing the tests on a clean environment with docker so that we can run tests on OS X and linux. |
All db should point to omf instead of wa now. As omf plugins have a different layout than wa. |
I see your point in it, but I do prefer following tagged releases in installer and updater, and keep master as "unstable" (where unstable means stable but not 100% sure of stability). I agree with what @bpinto proposes:
Yeah, this is something we inherited from a merge and we need to sort out. The thing to solve this issue (and others too) is a metadata file. See discussion in #196.
Oh My Fish still suffers from a violent merge we had in the past. Surely we need to get away from Wahoo packages by creating our own maintained packages, as this way we can evolve faster by having our own package maintainers. If you think you can port a
I agree with you, and this have been on my plans for months with the exact same data. We implemented package dependencies in #149, the next step is to add the metadata, again, see #196.
Help is very appreciated in this. We need maintainers, we also need better documentation. You are very welcome to help us with if you want. |
I've looked back at this issue and I now think that this should be high-priority, especially with the new changes planned. Features can't be merged quickly because it might damage user installations, and this is stalling development speed. Since this is a fairly simple project that moves forward generally, I don't expect backported patches to old versions, so I propose a simpler variant proposed by @derekstavis and @bpinto:
I am willing to implement this in the installer and in the updater immediately if I can get approval. |
I totally agree!
|
The dev branch never happened, so yeah, let's keep master as the bleeding-edge branch and tag releases as we go. |
I propose the following version scheme:
In addition, I propose following the below guidelines:
|
Hey Everyone For version numbers, can I humbly suggest [http://semver.org/](Semantec Versioning). I've seen it used well in the past, and it's pretty close to what @CoderStephen is suggesting. Only 1 potential area I'd change: for Minor versions you can add syntax, but not modify existing syntax. e.g. you would be ok to add a new --new-flag to an existing command, but the previous --old-flags would always need to behave as they did before without the new --new-flag. If the --new-flag caused new behaviour when omitted it should really be a new Major version. What do you think? Cheers |
P.S. Once you settle on a scheme, having this kind of info in a doc/wiki or somehting like that would be awesome 🐫 |
We've settled on a scheme, and we've now finally merged in support for updating to specific tags via PR #293, so marking this issue as closed. |
We need a way to versionate repository changes via git tags and ensure that
omf update
only fetch and upgrade using tags too. This way we can continue developing on master branch without breaking user installations. It will also make easier to report bugs and track them too.The text was updated successfully, but these errors were encountered: