f minor
> versions.
> > > I do understand you need a stable cloud, and that’s exactly what we’re
> > > achieving here.
> > > >
> > > > We changed our way of working from 4.6 on. Before that, it took _a
> > long_
> > > time to release
I totally agree Marcus, with one small addition. In our present scheme we
can mark any 4.x as LTS if we maintain the discipline of fixing any bug on
the oldest version known to contain the bug and merge the fix forward. some
LIMITATION OF WARRANTY (tm) apply of course; if a fix requires some kin
minor or patch). Releases were
> > not high quality so people waited for .1 or .2 to be released. When you
> did
> > eventually upgrade, you’d hit major trouble. It was simply not OK. And
> many
> > minor releases don’t help here. The root cause of the trouble is that the
;
> > We changed our way of working from 4.6 on. Before that, it took _a long_
> time to release new versions (be it major, minor or patch). Releases were
> not high quality so people waited for .1 or .2 to be released. When you did
> eventually upgrade, you’d hit major trouble. It wa
On 01/07/2016 05:04 PM, sebgoa wrote:
> Yet folks (like Rene) may like a pattern of just minor and very infrequent
> major. While folks like Remi want continuous deployment.
>
> So at the cost of sounding a bit "fatherly" we indeed need to discuss this a
> bit. I mentioned it after 4.6, and com
On 01/07/2016 05:27 PM, Remi Bergsma wrote:
> Anyway, I cannot and don’t want to convince you. We want something different
> and that is fine. What I do want to know is what others want. Because if the
> majority wants what you are asking for, we should do that.
It is not my decision, it is a
On Jan 7, 2016, at 5:27 PM, Remi Bergsma wrote:
>
> On 07/01/16 17:22, "Rene Moser" wrote:
>> No, it is not the pace. You can do as many major as often as you want
>> but if one uses this major, how long will it get minors? We have no clue.
>>
>> I understand your point completely while my ar
see inline
On Jan 7, 2016, at 3:39 PM, Nux! wrote:
> Hi,
>
>
>> So, yes, monthly releases can be done and the quality is better than before.
>> Actually, I think we should go much faster. Whenever a PR is merged that
>> fixes
>> your issue, it should be possible to deploy it right away. It’s a
Heaven is closer than you might think.
4.7 did not require a systemvm template change, so we reused the existing one.
No impact in upgrading. We need to change it only when needed, it’s that simple.
A separate project and version is probably best way forward.
Regards,
Remi
On 07/01/16 15:
;> I really wonder why.
>>
>
>
> Because with the current versioining scheme a new major release means new
> features/big changes = bugs = downtime.
> Atleast that is the assumption based on previous experience.
>
> More or less every major release before 4.6 had issues
> And that is indeed it. I'm not keen on doing point releases either.
> Simplify upgrade paths, ditch the fact that a VR has to be upgraded
> every time, etc, etc.
That'd be heaven. I hate the VR upgrades!
>
> We could also call 4.8 simply 4.7.2. It's just a number :)
+1, perhaps switch to ver
Hi,
> So, yes, monthly releases can be done and the quality is better than before.
> Actually, I think we should go much faster. Whenever a PR is merged that fixes
> your issue, it should be possible to deploy it right away. It’s a change in
> mindset.
This actually sounds very interesting; havi
On 01/07/2016 03:35 PM, Remi Bergsma wrote:
>
> We released:
> 4.6.0
> 4.6.1
> 4.6.2
> 4.7.0
> (4.7.1)
> (4.8.0)
>
> We _do_ release minor releases, and every month one with new features.
>
> To be clear:
> Any branch (be it 4.5, 4.6, 4.7) can have a
We released:
4.6.0
4.6.1
4.6.2
4.7.0
(4.7.1)
(4.8.0)
We _do_ release minor releases, and every month one with new features.
To be clear:
Any branch (be it 4.5, 4.6, 4.7) can have as many minor releases as people
want, until the end of time. Just step up and release it.
Regards,
Remi
>
, minor or patch). Releases were not high
quality so people waited for .1 or .2 to be released. When you did eventually
upgrade, you’d hit major trouble. It was simply not OK. And many minor releases
don’t help here. The root cause of the trouble is that the whole idea of
branching off a new version
15 matches
Mail list logo
