-
Notifications
You must be signed in to change notification settings - Fork 45
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
Implement automatic release #181
Conversation
Codecov Report
@@ Coverage Diff @@
## master #181 +/- ##
=======================================
Coverage 93.68% 93.68%
=======================================
Files 8 8
Lines 681 681
=======================================
Hits 638 638
Misses 43 43 |
This is awesome @smoia! It will be kind of hard to review I assume but it will clearly be worth it. Let me know if you need any help! |
@rmarkello, I'm sorry to bother but I think I need your help setting this up. Could you have a look at travis and its configuration? |
This is a shot in the dark, but can you try dropping from bionic back to xenial in the |
Mmm, unluckily that wasn't the issue. Any other idea? |
Just trying to see the issue here |
Ok, found it.
I truly wonder why. |
.autorc
Outdated
"prerelease": true | ||
}, | ||
"prereleaseBranches": [ | ||
"master" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you might be interested in [this](https://intuit.github.io/auto/pages/generated/shipit.html#without-%22next%22-branch-(--only-graduate-with-release-label)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
Wouldn't that unable us to automatically publish a release after every merged PR though?
From what I understand, that would trigger a new release only when the label release
is added to the PR.
Our intentions are a bit different: we are an open development project, that wants to release as soon as there is something new, even if we're still in beta production stage.
The "prereleaseBranches" set on master is temporary, until we get out of beta stage.
Then we will remove it.
After adding a couple of tags, and following @hipstersmoothie bug fix (thank you!), this is how the changelog would look like: v2.0.0 (Fri Mar 27 2020)💥 Breaking Change🚀 Enhancement
🐛 Bug Fix
|
@vinferrer the labels look ok (I'm going to add a |
changes done |
Hey @smoia! I see you're still working on this. When do you think we'll merge this? |
@eurunuela, I'm planning to merge it in as soon as we close our main milestone, or at least #30, #36, #185 . I'm sorry I worked on it again, but I just added a zenodo json file to configure its authorships automatically. Nothing much. |
Ok. I'm going to merge this after updating the auto release version. Finger crossed! 🤞 🤞 🤞 |
By the way, @hipstersmoothie is there a way to check the latest auto release without using npm? |
There currently isn't a good way. Maybe |
As we discussed in our February developer meeting, we will adopt an automatic release to keep phy2bids updated in pipy, respecting the cold, unemotional, robotic rules of semantic versioning.
Auto is a good tool for this: it operates using labels, rather than commit conventions such as angular, making it easier for everyone (especially less experienced contributors) to commit without fear. The idea is that every PR, if labelled correctly, will start the semantic versioning update.
Matched with a CI Pipy deployment, this should make our modifications be tracked at all times.
Proposed Changes