5:25 a.m.
If we do more releases, the releases process will become easier and
maybe even a non-event.
At least, I believe that paradox :)
Here's what I propose:
- For the next 4 weeks, until 22-JUL, we focus on big, risky features.
- The 2 weeks after that, until 5-AUG, we focus on bugfixing and /avoid
risky changes/.
On 5-AUG, I release 5.3.0.Beta1 directly from master.
If needed, we can call it 5.3.0.Alpha1 instead.
This will allow our users to verify backwards compatibility and new
features sooner
and give us feed-back sooner.
What do you think? Good idea or too ambitious?
--
With kind regards,
Geoffrey De Smet
5:37 a.m.
Hi,
I vote for that. More release more often => Less function per release =>
less risk
Regards
Nicolas
2011/6/24 Geoffrey De Smet <ge0ffrey.spam(a)gmail.com>
**
If we do more releases, the releases process will become easier and maybe
even a non-event.
At least, I believe that paradox :)
Here's what I propose:
- For the next 4 weeks, until 22-JUL, we focus on big, risky features.
- The 2 weeks after that, until 5-AUG, we focus on bugfixing and *avoid
risky changes*.
On 5-AUG, I release 5.3.0.Beta1 directly from master.
If needed, we can call it 5.3.0.Alpha1 instead.
This will allow our users to verify backwards compatibility and new
features sooner
and give us feed-back sooner.
What do you think? Good idea or too ambitious?
--
With kind regards,
Geoffrey De Smet
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
5:56 a.m.
It's most certainly something worth aiming for.
We need to ensure explicit time is given to bug fixing, so +1 from me :)
On 24 June 2011 11:37, Nicolas Héron <nicolas.heron.java(a)gmail.com> wrote:
Hi,
I vote for that. More release more often => Less function per release =>
less risk
Regards
Nicolas
2011/6/24 Geoffrey De Smet <ge0ffrey.spam(a)gmail.com>
> **
> If we do more releases, the releases process will become easier and maybe
> even a non-event.
> At least, I believe that paradox :)
>
> Here's what I propose:
> - For the next 4 weeks, until 22-JUL, we focus on big, risky features.
> - The 2 weeks after that, until 5-AUG, we focus on bugfixing and *avoid
> risky changes*.
> On 5-AUG, I release 5.3.0.Beta1 directly from master.
> If needed, we can call it 5.3.0.Alpha1 instead.
>
> This will allow our users to verify backwards compatibility and new
> features sooner
> and give us feed-back sooner.
>
> What do you think? Good idea or too ambitious?
>
> --
> With kind regards,
> Geoffrey De Smet
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
6:04 a.m.
Geoffrey De Smet píše v Pá 24. 06. 2011 v 12:25 +0200:
Here's what I propose:
- For the next 4 weeks, until 22-JUL, we focus on big, risky features.
- The 2 weeks after that, until 5-AUG, we focus on bugfixing and avoid
risky changes.
On 5-AUG, I release 5.3.0.Beta1 directly from master.
If needed, we can call it 5.3.0.Alpha1 instead.
+1 for a time-based fixed-length release cycle. It's quite popular these
days - Kernel, X.org, Fedora, Eclipse, recently Firefox... With Git,
it's very easy to keep stabilization branches and when Final is out, you
just merge all the changes back into master.
If it's done well, it makes the project more predictable and looks real
good.
--
Lukáš Petrovický
QA Engineer, JBoss Enterprise BRMS
Phone: +420 532 294 123
irc: lpetrovi, triceo
Red Hat Czech, s. r. o.
Purkyňova 99, 612 00 Brno, Czech Republic
5:34 a.m.
I don't believe we can ever get the release perfect, but knowing the dates right after
the previous release would help with the planning.
Maybe the last 2 weeks should be done using a release branch? We have community people
working on new features and using the master to get the codes stable would slow them down.
5.2.x branch was pretty long, still I didn't find it that hard to cherry pick and
merge my bug fixes.
Toni
On Jun 24, 2011, at 1:25 PM, Geoffrey De Smet wrote:
If we do more releases, the releases process will become easier and
maybe even a non-event.
At least, I believe that paradox :)
Here's what I propose:
- For the next 4 weeks, until 22-JUL, we focus on big, risky features.
- The 2 weeks after that, until 5-AUG, we focus on bugfixing and avoid risky changes.
On 5-AUG, I release 5.3.0.Beta1 directly from master.
If needed, we can call it 5.3.0.Alpha1 instead.
This will allow our users to verify backwards compatibility and new features sooner
and give us feed-back sooner.
What do you think? Good idea or too ambitious?
--
With kind regards,
Geoffrey De Smet
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
4700
days inactive
4704
days old
4 comments
5 participants
participants (5)
-
Geoffrey De Smet -
Lukáš Petrovický -
Michael Anstis -
Nicolas Héron -
Toni Rikkola