+1
On Wed, Mar 18, 2015 at 3:50 PM, Michael Kjellman <
mkjell...@internalcircle.com> wrote:
> For most of my life I’ve lived on the software bleeding edge both
> personally and professionally. Maybe it’s a personal weakness, but I guess
> I get a thrill out of the problem solving aspect?
>
> Rece
For most of my life I’ve lived on the software bleeding edge both personally
and professionally. Maybe it’s a personal weakness, but I guess I get a thrill
out of the problem solving aspect?
Recently I came to a bit of an epiphany — the closer I keep to the daily build
— generally the happier I
Hi,
Keep in mind it is a bug fix release every month and a feature release every
two months.
For development that is really a two month cycle with all bug fixes being
backported one release. As a developer if you want to get something in a
release you have two months and you should be sizing p
Hi,
Long lived feature branches are already a thing and orthogonal IMO to release
frequency. The goal is that developers will implement larger features as
smaller tested components that have already shipped. Some times this means
working in a less destructive fashion so you can always ship a wo
I like the idea but I agree that every month is a bit aggressive. I have no
say but:
I would say 4 releases a year instead of 12. with 2 months of new features
and 1 month of bug squashing per a release. With the 4th quarter just bugs.
I would also proposed 2 year LTS releases for the releases af
It would seem the practical implications of this is that there would be
significantly more development on branches, with potentially more
significant delays on merging these branches. This would imply to me
that more Jenkins servers would need to be set up to handle auto-testing
of more branche
If every other release is a bug fix release, would the versioning go:
3.1.0 <-- feature release
3.1.1 <-- bug fix release
Eventually it seems like it might be possible to be able to push out a bug
fix release more frequently than once a month?
On Wed, Mar 18, 2015 at 7:59 AM Josh McKenzie
wrote
Will we need to create new 3.0, 3.1, 3.2, ... deb repositories for each
monthly release? I'm not intimately familiar with the bintray redirects
that ASF Infra set up, recently, but we did have a few issues at first.
I'm wondering if this will require a redirect addition request to Infra
for eac
+1
On Wed, Mar 18, 2015 at 7:54 AM, Jake Luciani wrote:
> +1
>
> On Tue, Mar 17, 2015 at 5:06 PM, Jonathan Ellis wrote:
> > Cassandra 2.1 was released in September, which means that if we were on
> > track with our stated goal of six month releases, 3.0 would be done about
> > now. Instead, we
+1
On Tue, Mar 17, 2015 at 5:06 PM, Jonathan Ellis wrote:
> Cassandra 2.1 was released in September, which means that if we were on
> track with our stated goal of six month releases, 3.0 would be done about
> now. Instead, we haven't even delivered a beta. The immediate cause this
> time is bl
+1. This sounds like a step in a better direction.
Gary.
On Tue, Mar 17, 2015 at 4:06 PM, Jonathan Ellis wrote:
> Cassandra 2.1 was released in September, which means that if we were on
> track with our stated goal of six month releases, 3.0 would be done about
> now. Instead, we haven't even
+1
--
AY
On March 17, 2015 at 14:07:03, Jonathan Ellis (jbel...@gmail.com) wrote:
Cassandra 2.1 was released in September, which means that if we were on
track with our stated goal of six month releases, 3.0 would be done about
now. Instead, we haven't even delivered a beta. The immediate c
+1
I also appreciate Ariel’s effort. The improved CI integration is great - being
able to run a huge amount of tests on different platforms against one's
development branch is a huge improvement.
> Am 17.03.2015 um 22:06 schrieb Jonathan Ellis :
>
> Cassandra 2.1 was released in September, wh
+1
On Tue, Mar 17, 2015 at 10:06 PM, Jonathan Ellis wrote:
> Cassandra 2.1 was released in September, which means that if we were on
> track with our stated goal of six month releases, 3.0 would be done about
> now. Instead, we haven't even delivered a beta. The immediate cause this
> time is
14 matches
Mail list logo
