* On 22 Nov 2015, Kevin J. McCarthy wrote: > > I think we could relegate the even/odd versioning to history, apply a > > 1.6 tag as soon as we clear all in-flight bugfix patches, and continue > > with only one tagged series from there. (Development would simply be > > untagged.) > > I believe we're on the same page here. I was originally thinking about > one more 1.5.x release just to give more time, but I'm definitely open > to just pushing straight for a 1.6.0 as the next release. Recently, > I've mostly been focusing on bug fixes; I have the SMTPUTF8 series I'd > like to commit, but otherwise think a good next step would be working on > any major bugs and reviewing external patches.
Agreed - but in particular, I think that the 1.6 blockers in Trac are too big. They've been blocking 1.6 for years, and I think we're to the point now where 1.6 is more important than those particular issues. I think that we should bite only what we can chew for 1.6. > I'm also open to moving away from an odd/even scheme, and just having > releases. Our current stable/default branches do work well though, so > I'd like to keep using those as we are today, to be able to quickly > release security fixes if needed. I'm fine with stable/default branching. I assume this workflow: commit to default, merge to stable, tag releases from stable. I think the versioning split just hasn't really worked in our favor. > I know you have an extensive list of patches you maintain. Are > there any you'd like to get committed before 1.6.0? What about the > command-on-new-mail series? (No pressure, just asking...) Yes, I would like to (mainly that one and the keywords series), but if 1.6 is otherwise ready I don't want to be the reason it's not coming out. I may actually have some time to work on this in the next 5-6 weeks though. -- David Champion • [email protected]
signature.asc
Description: PGP signature
