On Sat, Jan 16, 2016 at 11:34:37PM -0800, Chris Brannon wrote: > Adam Thompson writes: > > > I'm wondering if we should start work on 3.7 at this point, > > hold off the release to get the major changes in. > > This is going to be a big change and I'm not sure I want to have minor releases > > differ quite so much when it comes to IPC. > > Really it shouldn't be a user-visible change. It shouldn't break your > build, and it shouldn't break backward compatibility. So I'd say stick > with putting it in a minor version number. Remember how big 3.6.0 was? > But let's get past named pipes and IPC. Once we have them in, working, > and well-tested, we can decide which version we want to put out next, or > whether we want to keep going and try to add more features. Shouldn't and won't are two very different words. In addition, I'd like to make the edbrowse-curl change prior to the next major release and don't particularly see the point in having a large IPC change in a minor release with no user-visible changes. I think we're better off getting the architecture right and tested then going for 3.7. > We're good to go for a 3.6.1 though, I believe. > Just give the word. Ok, given that Karl's object changes are in I say go for it. I also wonder, from a version control perspective, if it's worth then making a 3.6 branch where we can make bug fixes whilst playing with IPC stuff on Master? We should be able to merge or port these changes across but this will allow us to keep up with security and bug fixes whilst we make major, non-release-ready, changes to the development code. May be we focus on getting some of the object stuff working in the 3.6 minor releases and generally fixing that side of things and keep the IPC stuff etc for 3.7? My aim with these proposals is to increase the speed at which bug fixes can be released whilst allowing the big changes to happen concurrently. Cheers, Adam.