4.1 release timing

Folks -

Now that 4.0 is out it's clear that the next version will be 4.1. One
thing that I've noticed is that various people (both on and offlist)
have pointed out that it may be good if we'd release 4.1 ASAP in order
to both, minimize confusion (i.e., "4.0 is like 3.10") as well as keep
up momentum (i.e., make submissions for 4.0 and 4.1 on news sites).

Originally, I had hoped that we'd take a bit of time to talk about what
packages, documentation, and apps to package into 4.1 but doing that
does take time (we haven't even started the discussion yet) and would
make it impossible to do a very quick 4.1 release. I'm open either way
but I'm curious what the community thinks:

Would you prefer a very quick 4.1 release (4 weeks max) that *just*
packages up the current trunk state (no extra packages in order to save
time) or would you prefer that we take some time now discuss this
through before 4.1?

Personally, I'm good either way; anything that won't be getting done
this round will be in the next, but I think pepping the release up a bit
would be good, too :-) So I'm curious what the community thinks.

Cheers,
   - Andreas

>>>>> "Andreas" == Andreas Raab <[hidden email]> writes:

Andreas> Would you prefer a very quick 4.1 release (4 weeks max) that *just*
Andreas> packages up the current trunk state (no extra packages in order to
Andreas> save time) or would you prefer that we take some time now discuss
Andreas> this through before 4.1?

I'd be happy with a quick 4.1 release that represent's a year's improvement
on 4.0, and then take another year to really think out and develop 4.2.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Hi,

I'd very much favour a *quick* release, freezing the image *now* and
concentrating on making those tests green, AND on fixing bugs such as
the SqueakMap one - after having written tests for that. :-)

Best,

Michael

How about a few days notice to get some final enhancements in instead
of saying, "now", we should say, "at midnight on [xxx date a week
away]".

I have some things I've been testing / sitting on that I'd like not to
miss 4.1 / stable-release for a whole year..



On Wed, Mar 17, 2010 at 11:23 AM, Michael Haupt <[hidden email]> wrote:

On 17.03.2010, at 17:15, Randal L. Schwartz wrote:
+1 to a quick 4.1 release. Let's keep 4.2 out of the discussion for now.

- Bert -

Andreas Raab wrote:
 > Would you prefer a very quick 4.1 release (4 weeks max) that *just*
 > packages up the current trunk state (no extra packages in order to save
 > time) or would you prefer that we take some time now discuss this
 > through before 4.1?

For whatever it's worth, I think it would be grand to make a habit of
regular releases, so I vote for a quick 4.1

Ben

All in for a quickie and max 0.5y for 4.2

On Wed, Mar 17, 2010 at 17:30, Bert Freudenberg <[hidden email]> wrote:

> All in for a quickie and max 0.5y for 4.2

+1


Sam S. Adams, IBM Distinguished Engineer, IBM Research
Mobile: 919-696-6064, email: [hidden email]
Asst: Kenndra K. Quiles. (732) 926-2292 Fax: (732) 926-2455, email: [hidden email]
<<Hebrews 11:6, Proverbs 3:5-6, Romans 1:16-17, I Corinthians 1:10>>


[hidden email] wrote on 03/17/2010 12:43:13 PM:

>
> All in for a quickie and max 0.5y for 4.2
>
> On Wed, Mar 17, 2010 at 17:30, Bert Freudenberg <[hidden email]> wrote:
> > On 17.03.2010, at 17:15, Randal L. Schwartz wrote:
> >>
> >>>>>>> "Andreas" == Andreas Raab <[hidden email]> writes:
> >>
> >> Andreas> Would you prefer a very quick 4.1 release (4 weeks max)
> that *just*
> >> Andreas> packages up the current trunk state (no extra packages in order to
> >> Andreas> save time) or would you prefer that we take some time now discuss
> >> Andreas> this through before 4.1?
> >>
> >> I'd be happy with a quick 4.1 release that represent's a year's improvement
> >> on 4.0, and then take another year to really think out and develop 4.2.
> >
> > +1 to a quick 4.1 release. Let's keep 4.2 out of the discussion for now.
> >
> > - Bert -
> >
> >
> >
> >
>

On Mar 17, 2010, at 9:43 AM, Alexander Lazarević wrote:

> All in for a quickie and max 0.5y for 4.2
>


+1
Josh

Hi--

> Now that 4.0 is out it's clear that the next version will be 4.1. One
> thing that I've noticed is that various people (both on and offlist)
> have pointed out that it may be good if we'd release 4.1 ASAP in order
> to both, minimize confusion (i.e., "4.0 is like 3.10") as well as keep
> up momentum (i.e., make submissions for 4.0 and 4.1 on news sites).

     Yes, very good reasons to have a quick 4.1. We should get as much
benefit out of this publicity spike as we can.


-C

--
Craig Latta
www.netjam.org

2010/3/17 Craig Latta <[hidden email]>:
Indeed, Craig. It's important to move the trunk onto the official path
as soon as possible in order to avoid its marginalization and
contribute to its early adoption (to a more general public). But I'd
like to think that some kind of plan will be readily available for
4.2.

Ian.
--
http://mecenia.blogspot.com/

On Wed, Mar 17, 2010 at 08:59:44AM -0700, Andreas Raab wrote:
>
> Would you prefer a very quick 4.1 release (4 weeks max) that *just*
> packages up the current trunk state (no extra packages in order to save
> time) or would you prefer that we take some time now discuss this
> through before 4.1?

I prefer a quick 4.1 release, focus on current trunk state, save the
discussions for later.

Dave

+1
Ron

At 9:15 AM -0700 3/17/10, Randal L. Schwartz apparently wrote:
In my experience it is almost always better to think things through and fix known issues instead of rushing for some arbitrary deadline.
It is always better to fix things before they are released.
Do it right the first time.

Ken G. Brown

On 3/17/10 4:10 PM, "Ken G. Brown" <[hidden email]> wrote:

> In my experience it is almost always better to think things through and fix
> known issues instead of rushing for some arbitrary deadline.
> It is always better to fix things before they are released.
> Do it right the first time.
>
> Ken G. Brown
+10

>>>>> "Ken" == Ken G Brown <[hidden email]> writes:

Ken> In my experience it is almost always better to think things through and
Ken> fix known issues instead of rushing for some arbitrary deadline.  It is
Ken> always better to fix things before they are released.  Do it right the
Ken> first time.

And I don't think anyone is disagreeing with that.  But that's too abstract to
have a game plan.

If we feature-freeze 4.1, say, next monday, there's not a lot of reasons
why everything couldn't get greenlighted within a few weeks after that.
Might not make it, but it's a reasonable goal.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Freeze, fix, ship.

+1,000,000

On Wednesday, March 17, 2010, Randal L. Schwartz <[hidden email]> wrote:
--
Casey Ransberger

> +1,000,000

> +10

Guys, you've got only +/-1 to give away at a time. Don't abuse. ;P

Ian.
--
http://mecenia.blogspot.com/

I got carried away:)

On Wednesday, March 17, 2010, Ian Trudel <[hidden email]> wrote:
--
Casey Ransberger

At 11:13 AM -0700 3/17/10, Randal L. Schwartz apparently wrote:
Ok, I could see publishing the game plan, including all tests green, agree to the game plan then work towards it.

But for sure, don't push it out if the feature set is not met just to meet some arbitrary deadline.
That's what it is sounding like will happen.

Ken G. Brown