Hmm, I guess it makes sense if we interleave custom and master-based
releases. It may just create pain when backporting esp. given the branches
that do not share history. Also, after a master release all the subsequent
custom releases (other than dot releases in the previous custom releases)
must b
I’m not sure what would be confusing about the numbering. Assumably the next
feature bearing release will be 2.2. The next one after that 2.3. We should
make a rule that patches in version x don’t go away in x+1. With that I don’t
see any confusion.
I agree we shouldn’t turn master into a d
We need to figure out the versioning strategy for this that is not
hopelessly confusing.
Also, having too many fixes in master as described is a different problem,
of not releasing off master often enough.
What is to be done with master in this model?
On 16/11/29, 12:37, "Sergio Pena" wrote:
>Go
Good, thanks Owen for volunteering.
I see we have too many bugfixes, features, and improvements on the master
branch.
A few questions:
- How or what would be the process for cherry picking those fixes? How will
you detect which ones are stable and which not?
- What if others contributors want s
Hi all,
I'd like to volunteer as a Release Manager for making a stable feature
release from branch 2. However, rather than starting with master, I'll use
the 2.1 release and cherry pick fixes and features with a focus on a stable
release and picking features that have been tested at scale. Testi
