Comments (16)
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.
from oh-my-fish.
If I may, I like the idea of tagging releases. :)
Is there any way I can help?
p.s.
As an intermediate stage, it's also possible to do all development and testing on a dev branch and only push to master when it's stable.
from oh-my-fish.
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 :)
from oh-my-fish.
Naturally any version tag should point to a stable release.
On the upside, I wouldn't say that OMF is not stable, judging by the fact that everything seems to work fine right out of the box. I do, however, think that introducing named releases should be a planned move (and I'm not a huge fan of plans, if it means anything).
My humble suggestions are as follows:
- First things first - separate dev from master.
Fish newcomers are probably also OMF newcomers, and vice versa. If things get rough too soon, most of them will take a u-turn and never come back to either of them (see: vim). Fish is all about love on first sight. So perhaps now things are fine, but as long as anyone who uses OMF gets it straight from the master branch, it will become an impediment. Putting end-users and collaborators on the same branch means that end-users will have to put up with breakages and devs will have to tip toe.
Do development in topic branches, bug-fixes in dev, test from dev, push the ripe fruit to master, or something like that (see: git-flow). This is also not mutually exclusive with version tags, so why not do both anyway? - If you want to be taken seriously, I guess you should take yourself seriously. Not too seriously, obviously, but seriously enough to set a milestone and a few modest goals. Looking at the current issues and the way things are, I think OMF can and should strive to hit a milestone and have a proud first release tag.
- Plugins. pkg? plugin? omf-? Let's sort this out once and for all.
Now, to add to the confusion, let's take the gitignore (gi) plugin for example. There is a oh-my-fish/ repository and a wa/ repository for it. One seems very old, one seems newer. OMF's db points to the newer wa/ repository, but it has a very overt bug (trygi update
) and it's less well-organized (all functions in a single file). Why do these duplicates exist? It also comes with a consequence. I wanted to open an issue (and a PR), but couldn't decide where it should be. This perceived neglect is demotivating. - #152 and #196 lead to the same conclusion: Conventions are great, but packages can't rely on conventions alone anymore. It's cumbersome and not flexible enough. Besides, it makes the code more patch-y. Metadata should be a part of every package. Name, type, and dependencies. At some point there might be a need to add a version field. Descriptions can be optional. It shouldn't be too hard to implement and through this process we also get to do some house cleaning and make sure all plugins are up to date.
- I saw @bpinto's recent PR with some basic tests. I think that this is a great step forward to declare a certain build stable. Personally I would like it if there was some virtual OS X environment for testing. As a collaborator I want to make sure I don't make a fool of myself and other users. The same goes for a Linux environment, of course, but that's a piece of cake. You already have docker and it's easy to get a shell.
- Plugins. pkg? plugin? omf-? Let's sort this out once and for all.
from oh-my-fish.
Thanks for the suggestions! Let me see if I can comment on some of them.
- I really like this idea a lot. We should do this, basically immediately, since the current version is the version everyone uses anyway and is as "stable" as we have right now.
-
- We should be careful not to make things too complex though. After all, this is a shell customization framework, not a programming language dependency manager.
- Yay! I love tests. :)
- Well, some of the disorganization came recently from some... interesting project merging and restructuring and splitting and... stuff. Regardless, I do agree that we should do a little house cleaning.
from oh-my-fish.
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.
from oh-my-fish.
Do development in topic branches, bug-fixes in dev, test from dev, push the ripe fruit to master, or something like that (see: git-flow). This is also not mutually exclusive with version tags, so why not do both anyway?
I am not a fan of git-flow. I would rather avoid it and keep it simple:
- Master is the branch where new features are added to.
- Use feature branches for developing features.
- Use branches for major and minor versions.
- Use tags for patch versions.
- Default installation to a release (tagged commit).
from oh-my-fish.
I saw @bpinto's recent PR with some basic tests. I think that this is a great step forward to declare a certain build stable. Personally I would like it if there was some virtual OS X environment for testing. As a collaborator I want to make sure I don't make a fool of myself and other users. The same goes for a Linux environment, of course, but that's a piece of cake. You already have docker and it's easy to get a shell.
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.
from oh-my-fish.
Plugins. pkg? plugin? omf-? Let's sort this out once and for all. Now, to add to the confusion, let's take the gitignore (gi) plugin for example. There is a oh-my-fish/ repository and a wa/ repository for it. One seems very old, one seems newer. OMF's db points to the newer wa/ repository, but it has a very overt bug (try gi update) and it's less well-organized (all functions in a single file). Why do these duplicates exist? It also comes with a consequence. I wanted to open an issue (and a PR), but couldn't decide where it should be. This perceived neglect is demotivating.
All db should point to omf instead of wa now. As omf plugins have a different layout than wa.
from oh-my-fish.
First things first - separate dev from master.
(...) Putting end-users and collaborators on the same branch means that end-users will have to put up with breakages and devs will have to tip toe.
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:
- Master is the branch where new features are added to master (unstable).
- Use feature branches for developing features.
- Use branches for major and minor versions.
- Use tags for patch versions.
- Default installation to a release (tagged commit)
Plugins. pkg? plugin? omf-? Let's sort this out once and for all.
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.
There is a oh-my-fish/ repository and a wa/ repository for it.
This perceived neglect is demotivating.
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 wa/
namespaced package to oh-my-fish/
namespace we can allocate a repository for you.
Metadata should be a part of every package. Name, type, and dependencies. At some point there might be a need to add a version field. Descriptions can be optional.
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.
It shouldn't be too hard to implement and through this process we also get to do some house cleaning and make sure all plugins are up to date.
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.
from oh-my-fish.
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:
- Master is the branch where new features are added to master (unstable).
- Use feature branches for developing features.
- Use tags for major, minor, and patch versions.
- Default installation to a release (tagged commit)
I am willing to implement this in the installer and in the updater immediately if I can get approval.
from oh-my-fish.
I totally agree!
On Wed, 30 Mar 2016 at 15:47 Stephen M. Coakley [email protected]
wrote:
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 https://github.com/derekstavis and
@bpinto https://github.com/bpinto:
- Master is the branch where new features are added to master
(unstable).- Use feature branches for developing features.
- Use tags for major, minor, and patch versions.
- Default installation to a release (tagged commit)
I am willing to implement this in the installer and in the updater
immediately if I can get approval.—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#10 (comment)
from oh-my-fish.
The dev branch never happened, so yeah, let's keep master as the bleeding-edge branch and tag releases as we go.
And we can keep directing all PRs to master, exactly as we did so so far. I have yet to see a feature developed on a branch by more than a single contributor.
from oh-my-fish.
I propose the following version scheme:
- Major version: Indicates backwards-incompatible API changes. Also used when the project improvements seem significant enough for a new major version. Core contributors can feel this out as needed.
- Minor version: Indicates user-facing changes that change how user commands might be used, and new features released.
- Patch version: Bug fixes and minor improvements.
In addition, I propose following the below guidelines:
- Tagging a new major or minor version requires a consensus from the core team after testing the master branch, whether manually or automated (if more automated tests are added in the future). Releasing a patch version requires only one core contributor to verify that a bugfix works properly before release.
- If a more complex development workflow is required in the future, the system is open to change by core contributors.
- All releases must be accompanied by an addition in a
CHANGELOG.md
file in the project root. This file may possibly be used by OMF to show changelogs before updating, but is primary for users and contributors to quickly get up to speed on what has changed.
from oh-my-fish.
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
Sheldon
from oh-my-fish.
P.S. Once you settle on a scheme, having this kind of info in a doc/wiki or somehting like that would be awesome 🐫
from oh-my-fish.
Related Issues (20)
- Installation failure from curl on Pop-os HOT 4
- 'omf install powerline' responding with "Please install powerline" and not being usable HOT 1
- Is this project active? HOT 2
- Installer checksum in README.md isn't up to date.
- Print error: failed to parse choice argument: 2- HOT 2
- Cannot omf update or install packages
- All plugins
- Z
- OMF's offline installation doesn't really work offline
- Theme not updating even after using command for theme change.
- This no longer supports Fish 2.2.0
- Can't change the theme HOT 1
- I just install OMF and installed the cyan theme and this happened HOT 2
- I see a `[I]` in my fish! HOT 2
- oh-my-fish crashes Garuda-Update process HOT 2
- Remove [I] in the prompt HOT 1
- Installer does not check `$OMF_PATH` permissions
- Prompt Encoding as Question Mark HOT 2
- OMF not found no matter how hard i try to install it HOT 3
- fish get broken after vim run top or else HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from oh-my-fish.