From: | Stephen Nelson <stephen(at)eccostudio(dot)com> |
---|---|
To: | Steven Schlansker <stevenschlansker(at)gmail(dot)com> |
Cc: | Dave Cramer <davecramer(at)gmail(dot)com>, List <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: release process |
Date: | 2015-02-18 22:27:10 |
Message-ID: | CAHpHs3=nzW3asaLA3mR6sJs6jzWJQybvcTChSLm_H9NeOgT1Qg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
On Wed, Feb 18, 2015 at 4:59 PM, Steven Schlansker
<stevenschlansker(at)gmail(dot)com> wrote:
>
> +1 to both. You can always make a branch later from the tag if you need to release a patch version.
>
> > On Feb 18, 2015, at 8:57 AM, Dave Cramer <davecramer(at)gmail(dot)com> wrote:
> >
> > The current release / branching seems onerous. I'm wondering if it wouldn't be easier to just have a master branch going forward and just tag releases ?
> >
> > I'd also like to consider moving away from the numbering scheme paralleling the server numbering scheme
> >
> >
> > Thoughts ?
> >
>
+1
I've always thought the same with source branches. Maybe set a policy
to support the current server version plus some number of previous
versions? Older than that is on a best effort basis?
I think moving away from the server version numbering could be
advantageous, particularly as I had made the mistake in the past, that
you need to match server and client version. Although changing it now
could confuse users as it has historically tracked the server version.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2015-02-19 16:27:23 | setFetchSize with ResultSet.TYPE_SCROLL_INSENSITIVE |
Previous Message | Steven Schlansker | 2015-02-18 16:59:47 | Re: release process |