-
Notifications
You must be signed in to change notification settings - Fork 41
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
update release process to make releases for commits #1543
Comments
@danisharora099 to update the issue to instead have tagged releases for master commits -- |
unstable
as proxy master
something that's quite nice with nwaku release process: waku-org/nwaku#2006 (comment) |
next step:
@danisharora099 why is it a priority? |
not a priority, but we put it there as it should be a fairly less time consuming task iirc |
@weboko moving this to priority to enable testing unreleased, but merged, code in examples in a way which does not take too much time or friction and as I understand should not take too much time. I'm happy to take this up |
I agree it should be done rather early, should be useful |
TODO:
|
I'd suggest to make PR for merged PRs, not all commits. |
@fryorcraken do you mean similarly how |
My input was just to release for specific PR merge commit I guess. not every commit of the feature branch. |
Addressing it here #1702 |
Problem
We currently make releases for the
master
HEAD every month. This introduces delays to test the functionality as we need to do a release to use the new HEAD.Proposed Solutions
The proposal is to release commits that are merged to
master
tagged with their commit hash or even make nightly releases perhaps.This allows consumers (and us) to be able to test these functionalities outside of the scope of js-waku with ease.
Notes
While some solutions like building
js-waku
locally and using the build files directly are still possible, they are not as frictionless of a process.The text was updated successfully, but these errors were encountered: