-
Notifications
You must be signed in to change notification settings - Fork 59
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
Repository branching and tagging, versioning #46
Comments
Hi @ThomDietrich The only thing I did not think about was the "Tags" tab. Great idea! 👍 |
e0e3bad ✨ |
@marvinroger just a thought before it's too late. After all recent additions and changes I wonder if 2.1.0 is the correct version to choose. How about 3.0.0 or 2.5.0? Btw I believe that not having any versioning right now (and for the last couple of weeks) is not good... |
I agree that v3.0.0 would be semver-compliant. I don't know, because the v2 was actually never released. But yes, the versioning was chaotic. Let's follow semver and go for v3. 😈 We'll have it ready very soon, that'll be a thing of the past. 😉 |
Hi @marvinroger! What's left for the release of the official Homie 3.0 version? All PR's are merged and all big issues are closed, what else needs to be done? Many thanks for all your hard work! 👍 |
@marvinroger I really think the current repo situation is all other than ideal. We should do something about that... You can always start by creating a beta release or similar... Everything is better than the current state. |
Added some tags and releases, getting close :) |
@timpur thanks for pushing development forward. I'd suggest to do a few things right away, in order to finally reach a production ready and extendable state:
... So basically enforce everything I've noted down in the first message here 😃 What do you think? |
@timpur did you miss the mentioning? What do you think? If you are not disinclined, I'd go and apply the changes tomorrow. |
Yes, just stretched for time atm .... |
@timpur @marvinroger |
What are some of the big issues atm, tbh not following them all ... but yest i think were ready for 3.0 |
Definitely!
Sorry for my tiny presence here, I have been preparing my internship
defense, which is tomorrow! 😊
Le lun. 19 févr. 2018 à 13:56, Thomas Dietrich <notifications@github.com> a
écrit :
… @timpur <https://github.com/timpur> @marvinroger
<https://github.com/marvinroger>
I might have overestimated my free time back in the last comment :D
Just so we are all on track: Do we want to go forth with the plan to mark
version 3.0 now, then address all existing issues? A simple 👍 would be
enough to show your approval. 😉 I'll do the needed work then.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#46 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA8eNYO7LWvql-JmbkTdi60Ec3Vd55DZks5tWW-KgaJpZM4PjPFh>
.
|
@marvinroger Good luck! |
@ThomDietrich, Do what you can and ill help when i can :) Thank for contributing. |
Hope that everything went fine @marvinroger! Thanks for all your work guys! |
Question, how do you guys prefer to do implementation versioning? eg ESP implementation? Should it align with Homie version? or independent and just state what version of homie its using? |
Yes, IMHO it should be clear what versions of both match |
yes but what :P ? |
H3.0ESP23.04 |
Damn |
Could be: |
@marvinroger need you to remove v2 branch, and set master as default. I have merged and cleaned up branch v2 so you can remove. Master sits at v2.0 now and is ready for redesign branch (3.0) we will work on redesign and master will reflect most recent release always. We now need to get 3.0 ready for release. |
@timpur I have to apologize. I ran into some unforeseen problems in my personal endeavors and didn't get around to continue here. Thanks for taking matters into your hands. One thought I want to mention: You've changed "2.1.0" to "3.0" but it should read "3.0.0". Is this a mistake? Please compare: http://semver.org/ |
Didn't know what existed .... Good to know. My mistake, will fix |
Yes, but what's your problem with a v2.0.x branch? There is no need to merge it back. |
Exactly. You will see that everything falls into place once you start working on it. @euphi regarding the branch name. After consideration, I wonder if we should prefer |
Okay, if you dont thing git will garbage collect the unmerged commits in a deleted branch with a tag then sure. Im all in. Should we just squash and merge PRs ? |
@timpur |
@ThomDietrich
|
@marvinroger the master branch is protected and I can't push destructive changes. (Good so far! 😉)
@euphi ultimately I've no strong feeling to one or the other. In another project I'm involved in we do something similar with |
@ThomDietrich done 😉 |
Wait I thought the whole point of this was to only have one branch master and use feature branches only to make changed but they eventually get merged and deleted ? So won't 2.0.1 be the same. I'll tag it and relase it and then delete the branch ? |
No, that's just not possible. The github flow and git flow models don't consider maintaining an old release, so we can't use them.
|
Are we ready to move to @homieiot? No immediate concerns about that? I am just wondering, should we name it homieiot/homie or homieiot/convention? One thing, I'd like to create a website that would render the convention markdown, and having it as https://homieiot.github.io/convention sounds cleaner than https://homieiot.github.io/homie |
Oh and yes @ThomDietrich, I remember that we already discussed about moving the convention to its own org. I was then looking for a job, and my GitHub weighted more than my CV. I am now in a comfortable position, so now that my career is "bootstrapped", I have no problem moving the convention. 😉 |
I also prefer "convention". |
Regarding moving to homieiot? Should we fork the repository to keep history or should we create a new Repo? For creating a website, the directory structure will change, so maybe a new repo is better? So before moving the contents, we should clarify:
|
@marvinroger great. looks good now. @euphi we don't have to worry about history. Moving a repo just means it will be shifted into another namespace. Btw. GitHub will auto-redirect the current repo URL to the new one so that links and users will still find their way. @marvinroger we are in total sync :D I was also thinking about https://homieiot.github.io/convention 😉 |
Sounds good guys :) |
Let's all welcome the new |
Wonderful. You might want to adapt the short description of the project to include "Homie". I'd say the issues of this issue are settled. However let's leave it open as a reference. |
Just did. Thanks to everyone! 👏 |
Just noticed the NodeJS implementation merged on Sept. 21 2017 didn't make it to the Home Page v2.0 or the new Implementations page. Probably an artifact of repository movement - although if it were an accident, I wonder what other commits fell through the cracks... |
@lorenwest Done :) |
Would you mind also adding back to https://github.com/homieiot/convention/tree/release-v2.0.x ? That's the version it was developed against. I'll update as soon as 3.x moves from WIP to LIVE. |
@lorenwest Done, sorry should of thought about. Also you might want to define a version and link to one of the releases of Homie. https://github.com/homieiot/convention/releases :) |
Hello @marvinroger,
Somewhere in comments we already discussed that branching in this repository should be addressed. I want to restart that discussion. Here's my first suggestion, which is open for discussion:
Introduce a strict versioning system - Homie is a convention to be followed by other development projects. It is hence important to add unambiguous version numbers for every convention revision. A developer needs to be able to state "The app conforms with the Homie convention v2.1.3". I suggest to implement semantic versioning: http://semver.org (should be a perfect fit)
Work in the
main
branch only - Currently there is an outdated master branch, an unclear v2.0 branch and a redesign branch. That is neither intuitive nor visible to a reader. As the convention is steadily evolving, we should present the latest revision to the interested developer/user. (With the option to switch to other versions, see 5)Use tags to mark versions - A homie version is a fixed state of the document, hence tags are perfectly fine for the job. (Other branching models suggest branches in order to allow e.g. hotfixes)
Version every commit - Almost every commit will change details of the Homie convention, it is therefore needed to increment the version number as the MAJOR.MINOR.PATCH system of semver suggests. (Exceptions are of course commits with language changes only)
GitHub releases for stable tags - GitHub offers the releases tab to publish versions and add a release note. That should be used to announce and document the stable and noteworthy releases (e.g. v1.5.0, v2.0.0, v2.1.0)
Link the "Tags" tab in the first part of the convention - For readers to quickly find all available homie versions, the tags tab should be highlighted in the first part of the convention document.
Everyone, please add your comments, criticism and feedback!
Best! Thomas 🍻
The text was updated successfully, but these errors were encountered: