3.0.3.2 or 3.0.4

> I've done just about as much as I need to do in the Seaside3.0 port to
> GemStone3.0 so I'm ready to release 3.0.3.1.
>
> The next round of work that I'd like to do is make a pass through Magritte2
> and Pier2 picking up the latest versions of mcz files and start propagating
> symbolic versions through the Seaside/Magritte/Pier configuration ecosystem
> .... there are several places where symbolic versions can be used to
> improved the configurations that depend upon ConfigurationOfSeaside30.
>
> At a minimum I'd like to incorporate symbolic versions into Seaside for the
> handful of projects that Seaside3.0 depends upon. To that I'd need to crank
> out a new version and it would make sense to use version 3.0.3.2...if that
> was all I did.
>
> On the other hand, if 3.0.4 is ready to go out the door, I could update to
> the latest packages, port to GemStone and test on Squeak in addition to the
> symbolic version work and then of course use 3.0.4.
>
>
> So what do you guys think? Is 3.0.4 ready to rumba?

> 2011/2/8 Dale Henrichs<[hidden email]>:
>> I've done just about as much as I need to do in the Seaside3.0 port to
>> GemStone3.0 so I'm ready to release 3.0.3.1.
>>
>> The next round of work that I'd like to do is make a pass through Magritte2
>> and Pier2 picking up the latest versions of mcz files and start propagating
>> symbolic versions through the Seaside/Magritte/Pier configuration ecosystem
>> .... there are several places where symbolic versions can be used to
>> improved the configurations that depend upon ConfigurationOfSeaside30.
>>
>> At a minimum I'd like to incorporate symbolic versions into Seaside for the
>> handful of projects that Seaside3.0 depends upon. To that I'd need to crank
>> out a new version and it would make sense to use version 3.0.3.2...if that
>> was all I did.
>>
>> On the other hand, if 3.0.4 is ready to go out the door, I could update to
>> the latest packages, port to GemStone and test on Squeak in addition to the
>> symbolic version work and then of course use 3.0.4.
>>
>>
>> So what do you guys think? Is 3.0.4 ready to rumba?
>
> I'm not sure about the fix for Issue 640 (Seaside-Core-as.694,
> Seaside-Core-as.695). I'd like to discuss that first with Lukas.
>
> Cheers
> Philippe
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

> On Tue, Feb 8, 2011 at 5:51 AM, Philippe Marschall
> <[hidden email]>  wrote:
>> 2011/2/8 Dale Henrichs<[hidden email]>:
>>> So what do you guys think? Is 3.0.4 ready to rumba?
>>
>> I'm not sure about the fix for Issue 640 (Seaside-Core-as.694,
>> Seaside-Core-as.695). I'd like to discuss that first with Lukas.
>
> Agreed. I don't think we can release with that issue in the state it's
> in. We can easily revert it and release though, if anyone's keen.
>
> Julian
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

> On 02/08/2011 11:11 AM, Julian Fitzell wrote:
>>
>> On Tue, Feb 8, 2011 at 5:51 AM, Philippe Marschall
>> <[hidden email]>  wrote:
>>>
>>> 2011/2/8 Dale Henrichs<[hidden email]>:
>>>>
>>>> So what do you guys think? Is 3.0.4 ready to rumba?
>>>
>>> I'm not sure about the fix for Issue 640 (Seaside-Core-as.694,
>>> Seaside-Core-as.695). I'd like to discuss that first with Lukas.
>>
>> Agreed. I don't think we can release with that issue in the state it's
>> in. We can easily revert it and release though, if anyone's keen.
> Personally, I'd rather focus on getting the symbolic version ecosystem
> cleaned up which can be done in 3.0.3.2, but if it's time to push 3.0.4,
> I'll roll the two tasks into one.

> On Tue, Feb 8, 2011 at 7:29 PM, Dale Henrichs<[hidden email]>  wrote:
>> On 02/08/2011 11:11 AM, Julian Fitzell wrote:
>>>
>>> On Tue, Feb 8, 2011 at 5:51 AM, Philippe Marschall
>>> <[hidden email]>    wrote:
>>>>
>>>> 2011/2/8 Dale Henrichs<[hidden email]>:
>>>>>
>>>>> So what do you guys think? Is 3.0.4 ready to rumba?
>>>>
>>>> I'm not sure about the fix for Issue 640 (Seaside-Core-as.694,
>>>> Seaside-Core-as.695). I'd like to discuss that first with Lukas.
>>>
>>> Agreed. I don't think we can release with that issue in the state it's
>>> in. We can easily revert it and release though, if anyone's keen.
>> Personally, I'd rather focus on getting the symbolic version ecosystem
>> cleaned up which can be done in 3.0.3.2, but if it's time to push 3.0.4,
>> I'll roll the two tasks into one.
>
> I don't think there's a need to do a new version at all, but I'd
> personally rather avoid 4-level version numbers if we're going to talk
> about them publicly. If you're keeping the code identical to 3.0.3,
> we're still referring to it as 3.0.3, and the version number bump is
> just internal paperwork to do with the metacello config, then that's
> fine. Otherwise, if the metacello change has to happen now, I'd push
> to do a 3.0.4 - version numbers are cheap.
>
> Julian

> On 02/08/2011 01:49 PM, Julian Fitzell wrote:
>> I don't think there's a need to do a new version at all, but I'd
>> personally rather avoid 4-level version numbers if we're going to talk
>> about them publicly. If you're keeping the code identical to 3.0.3,
>> we're still referring to it as 3.0.3, and the version number bump is
>> just internal paperwork to do with the metacello config, then that's
>> fine. Otherwise, if the metacello change has to happen now, I'd push
>> to do a 3.0.4 - version numbers are cheap.
>
> I will be publicizing the release so it's not just an internal version,
> there are GemStone-specific bugfixes/features along with symbolic version
> information, but the basic functionality shouldn't be any different 3.0.3.
>
> So that means I'd use 3.0.4 for the work I'm doing, and the outstanding mcz
> files and bugfixes would be moved to 3.0.5

> On Tue, Feb 8, 2011 at 11:14 PM, Dale Henrichs<[hidden email]>  wrote:
>> On 02/08/2011 01:49 PM, Julian Fitzell wrote:
>>> I don't think there's a need to do a new version at all, but I'd
>>> personally rather avoid 4-level version numbers if we're going to talk
>>> about them publicly. If you're keeping the code identical to 3.0.3,
>>> we're still referring to it as 3.0.3, and the version number bump is
>>> just internal paperwork to do with the metacello config, then that's
>>> fine. Otherwise, if the metacello change has to happen now, I'd push
>>> to do a 3.0.4 - version numbers are cheap.
>>
>> I will be publicizing the release so it's not just an internal version,
>> there are GemStone-specific bugfixes/features along with symbolic version
>> information, but the basic functionality shouldn't be any different 3.0.3.
>>
>> So that means I'd use 3.0.4 for the work I'm doing, and the outstanding mcz
>> files and bugfixes would be moved to 3.0.5
>
> I'm now a bit confused what the constraints are. Are you saying you'd
> prefer not to include the other changes in the same release?
>
> My preference (and what it sounded like Philippe was saying) is that
> if you need to do an "official/public" release anyway, we should
> release the changes that have been made since 3.0.3, plus your
> changes, as 3.0.4. The commits from Issue 640 have been reverted, so
> we should be in good shape again and that fits with our new strategy
> of doing small releases more often.
>
> Julian