Automated releases

[voidpumpkin]

What if we released a new yew version after every commit? At least while we are in 0.x.x versions.

• This would enable new features faster bug discoverability as more people use the new feature.
• 0.x.x versions mean breaking changes all the time anyway.
• Updating change log could be mandatory with each PR, this would mean easier traceability of what has been done.
• Yew is driven by its community, we have no full-time paid maintainers, so why not allow people to hit their features live as fast as possible and remove the need for maintainers to write everything to the change log?
• To discourage use of too WIP features we could hide them under by default disabled cargo features.

At the time of writing this I am not sure how this can be implemented.

[voidpumpkin]

@siku2 I would love your input on this

[siku2]

Also, the pre-releases will be fully automatic and can be downloaded from crates.io too. It's just the 'stable' releases that need to be maintainer approved.

[voidpumpkin]

Then the prelease stuff sounds great.

Who has access to crates-io from maintainers, do you?
Would be great to at least investigate this how it could be done.

[siku2]

Yes, I have access to the crates.

[voidpumpkin]

@siku2 We could prototype some flow, perhaps we should move this discussion somewhere visible only to maintainers?

[ranile]

Will those "pre-releases" cause conflicts with dependencies? Releasing a "stable" (right now a minor version) more frequently sounds better to me. We can automate that to happen when a GitHub release is created.

The problem is I see with pushing too many releases to crates.io is that different libraries would use different versions of Yew (not everything can keep up with the releases, especially since there are breaking changes in them) and using them in project would cause dependency conflicts. Think of a situation where the binary depends on one version of Yew and a library depends on another version.

[siku2]

Most strategies for automatic releases I can think of are somewhat limited because of Yew's mono repo structure. Perhaps we should switch to a unified versioning scheme for all crates in the mono repo and always release them together.

[ranile]

That would limit us to releasing everything together. Meaning we can't push a release to router without also pushing a release for everything else. We don't really do that now so not sure how much it matters

[ranile]

Automated releases on crates.io when a Github release is created sounds like a good first step. More frequent releases would be good to have

[voidpumpkin]

Your raised issues do concern me... I agree lets focus on this first