On 07/04/17 14:52, A. Soroka wrote:
I'm fine with trying for regular x.x.0 releases, but I would add two provisos:
1) We should have a calendar as well, particularly while we have a single
codebase with two sync'd release products. In other words, we should do a
release when either enough development has accumulated to justify a minor
release or six months have passed. Otherwise we are waiting for arbitrary
unscheduled work to complete to be able to release.
Previously, we agreed a release every 3 months (kind unspecified),
having moved from every 6 months.
How about aim for a release every 3 months, with the option to decide to
stretch that out if there isn't enough activity to make it worthwhile.
(If 3 months is a bit of a stretch, 4 months.)
Of course, a release can happen at any time in a "as needed, as
resourced" basis.
2) We need to develop some kind of strategy for maintaining a core and
"exterior" modules. We've already begun those discussions and I don't think
anyone is opposed to this. Having a large codebase completely locked together is not a
good stance for flexibility or being able to do releases.
Lastly, if no one else (modulo Andy) is interested, and if Andy would rather
not, I will do the 3.3.0 release. But having done the last one, let me
encourage any committers who haven't released to think about doing it. It
wasn't difficult and I got to learn a good bit about Apache release mechanics
quickly.
Thank you.
Andy
---
A. Soroka
The University of Virginia Library
On Apr 7, 2017, at 9:38 AM, Rob Vesse <[email protected]> wrote:
A big +1 to the proposed strategy
Having more regular releases with whatever is ready is preferable to holding
back work for the right release
Rob
On 07/04/2017 14:21, "Andy Seaborne" <[email protected]> wrote:
On 07/04/17 11:26, Osma Suominen wrote:
05.04.2017, 20:32, Andy Seaborne kirjoitti:
If we have a 3.x.0/clocktick style, maybe we can better evolve more
easily - removing deprecations for example.
What do you mean by clocktick style? Do you mean the .0/.1/.0/.1 style
that has been followed recently (until 3.3.0 which will break the
pattern) or the opposite where most/all releases are just 3.x.0?
Our general level of stability/compatibility would be just as strong as
has been.
So far:
3.0.0, 3.0.1, 3.1.0, 3.1.1, 3.2.0, 3.3.0
2.11 even got to 2.11.2.
We can only do 3.x.1 if everything is 3.x.1.
I think there are two options:
1. Make an explicit strategy of alternating between .0 and .1 releases.
Big changes can only go into .0 releases, while .1 releases are reserved
for non-intrusive fixes.
2. Generally do only x.x.0 releases. However, if a "brown paper bag"
issue comes up soon after a release, we could still do a .1 to fix just
that specific issue.
I like 2. more than 1. because it allows more freedom for subsystems to
evolve on their own.
+1 to (2)
That is what I was getting at.
This makes our work as decoupled/asynchronous as possible.
This is not a big change. We have fallen into x.y.1 but I think because
that is what maven release plugin defaults to, no other reason.
A (3) is two branches - dev and maintenance each with releases. Given
we are people-time-limited, I feel that's not viable.
-Osma
Andy
