On Thu, Sep 13, 2012 at 9:54 AM, Martijn Dashorst <
martijn.dasho...@gmail.com> wrote:
> On Thu, Sep 13, 2012 at 4:45 PM, Jeremy Thomerson
> wrote:
> > My OCD side wonders if we should have used two-digit numbers ( at least
> for
> > y and z ) to improve sortability (6.01.00) ... but then those l
+1 (non-binding)
Kind regards,
Andreas
On Thu, Sep 13, 2012 at 4:40 PM, Martijn Dashorst
wrote:
> As for performing the releases, I propose we maintain a ~4 week
> schedule for x.y.0 releases, and reserve x.y.z (z > 0) for botched
> releases.
>
> So our release calendar would become something li
On Thu, Sep 13, 2012 at 4:45 PM, Jeremy Thomerson
wrote:
> My OCD side wonders if we should have used two-digit numbers ( at least for
> y and z ) to improve sortability (6.01.00) ... but then those look kind of
> ugly.
FUGLY is a proper characterization. And I just say that we should
probably st
On Thu, Sep 13, 2012 at 9:40 AM, Martijn Dashorst <
martijn.dasho...@gmail.com> wrote:
> As for performing the releases, I propose we maintain a ~4 week
> schedule for x.y.0 releases, and reserve x.y.z (z > 0) for botched
> releases.
>
> So our release calendar would become something like:
>
> 6.1
+1
On Thursday 13 September 2012 16:40:19 Martijn Dashorst wrote:
> As for performing the releases, I propose we maintain a ~4 week
> schedule for x.y.0 releases, and reserve x.y.z (z > 0) for botched
> releases.
>
> So our release calendar would become something like:
>
> 6.1.0 -> build on fri
As for performing the releases, I propose we maintain a ~4 week
schedule for x.y.0 releases, and reserve x.y.z (z > 0) for botched
releases.
So our release calendar would become something like:
6.1.0 -> build on fri 21-09-2012 -> release on tue 25-09-2012
6.2.0 -> build on fri 19-10-2012 -> relea
On Thu, Sep 13, 2012 at 9:34 AM, Martijn Dashorst <
martijn.dasho...@gmail.com> wrote:
> On Thu, Sep 13, 2012 at 4:25 PM, Jeremy Thomerson
> wrote:
> > So, just to be clear - this means that when I fix a bug in master right
> now
> > I put fix version of "6.1.0" in, right?
>
> Yup.
>
> I propose
On Thu, Sep 13, 2012 at 4:25 PM, Jeremy Thomerson
wrote:
> So, just to be clear - this means that when I fix a bug in master right now
> I put fix version of "6.1.0" in, right?
Yup.
I propose that for each back port to a possible x.y.z release we at
least ping dev@ prior to making one: it costs
On Tue, Sep 11, 2012 at 8:18 AM, Andrea Del Bene wrote:
> +1 for B. IMHO it's more rational
>
> We now live in a semver world and we need to agree on some basics: how
>> we are going to maintain and release our software.
>>
>> From what I have heard from several folks in jira, mail, IRC and
>> d
+1 for B. IMHO it's more rational
We now live in a semver world and we need to agree on some basics: how
we are going to maintain and release our software.
From what I have heard from several folks in jira, mail, IRC and
direct communication is that we have basically 2 camps:
A. develop and re
+1 for opt B from my side too (non-binding)
Kind regards,
Andreas
On Mon, Sep 10, 2012 at 8:14 PM, Johan Compagner wrote:
> I am interested in your article..
> How else to really do it then cherry picking.. but I guess h that also
> depends where you do you're good first?
> I always start at the
I am interested in your article..
How else to really do it then cherry picking.. but I guess h that also
depends where you do you're good first?
I always start at their lowest version I want to fix it and forward port
it, almost never do back ports
Op 10 sep. 2012 19:33 schreef "Carl-Eric Menzel"
+1 for B as well.
We also need to think about how we will actually *do* the branching,
and especially the merging. So far what I've seen were three totally
separate branches with only cherry-picking going in between them. In my
opinion, that's not a very good way to use git, which is far more
powe
+1 for option B.
-igor
On Mon, Sep 10, 2012 at 5:31 AM, Martijn Dashorst
wrote:
> We now live in a semver world and we need to agree on some basics: how
> we are going to maintain and release our software.
>
> From what I have heard from several folks in jira, mail, IRC and
> direct communicatio
I opt for the strategy B. Semver dictates that bugfixes should not contain new
features. If we stay on 6.0, we cannot add any new features. If I look at
JIRA, I already see 6 fixed tickets marked as 'improvement': 4730, 4731, 4736,
4745, 4746 and 4748. If we really want to follow semver, these s
We now live in a semver world and we need to agree on some basics: how
we are going to maintain and release our software.
>From what I have heard from several folks in jira, mail, IRC and
direct communication is that we have basically 2 camps:
A. develop and release bug fixes until we we start de
16 matches
Mail list logo