edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Adam Thompson <arthompson1990@gmail.com>
To: Chris Brannon <chris@the-brannons.com>
Cc: Edbrowse-dev@lists.the-brannons.com
Subject: Re: [Edbrowse-dev] Named Pipes
Date: Sun, 17 Jan 2016 10:16:19 +0000	[thread overview]
Message-ID: <20160117101619.GA11059@122oven.adamthompson.me.uk> (raw)
In-Reply-To: <87pox04q2a.fsf@mushroom.localdomain>

[-- Attachment #1: Type: text/plain, Size: 1986 bytes --]

On Sat, Jan 16, 2016 at 11:34:37PM -0800, Chris Brannon wrote:
> Adam Thompson <arthompson1990@gmail.com> 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

      reply	other threads:[~2016-01-17 10:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20160008145150.eklhad@comcast.net>
     [not found] ` <20160109082016.GA2925@122oven.adamthompson.me.uk>
2016-01-09 13:12   ` Karl Dahlke
2016-01-09 14:26     ` Adam Thompson
2016-01-09 16:36       ` Karl Dahlke
2016-01-17  7:34       ` Chris Brannon
2016-01-17 10:16         ` Adam Thompson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160117101619.GA11059@122oven.adamthompson.me.uk \
    --to=arthompson1990@gmail.com \
    --cc=Edbrowse-dev@lists.the-brannons.com \
    --cc=chris@the-brannons.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).