Grr, stupid GMAIL decided to send before I was finished.
1) Commit my pending mutablebuffer api changes.
2) Copy trunk to my sandbox to preserve the current state.
3) Take a crack at snipping out the bits that are not ready for primetime
yet. I'm thinking this might be an easier task than trying to merge changes
into the release branch.
4) Assuming 3 is workable, complete the pending work on the stack frames
and the APIs.
Rick
On Wed, Nov 20, 2013 at 9:30 AM, Rick McGuire <[email protected]> wrote:
>
>
>
> On Wed, Nov 20, 2013 at 9:16 AM, Mark Miesfeld <[email protected]> wrote:
>
>> Rick,
>>
>> I think I just updated the readme.version file in the root directory of
>> 4.1.fixes and was using that.
>>
>> Some other details you may or may not have thought about. The doc branch
>> used for 4.1.3 is mostly not updated to the new format that is docs trunk.
>> It might be easier to use docs trunk for 4.2.0 and remove some things then
>> to branch the 4.1.3 docs to 4.2.0.
>>
>
> Ah, I had forgotten about the doc format. As I was browsing the list of
> changes, there's one part of the exception work I'd really like to keep.
> That's the whole stack frame bit and the enhancements to the error
> tracebacks. Those pieces still need to have some docs written and also
> some unit tests. The current test suite trunk is already using those new
> features, so there's another intersection there. I also have some API
> enhancements for MutableBuffer support that's currently only in my working
> copy it might be nice to add.
>
> Before I create a branch from 4.1.3 and attempt to merge anything back in,
> here's what I'm going to try first.
>
> 2) Make a snapshot of trunk to my sandbox to preserve what I've written.
>
>
>>
>> In ooRexx trunk, you had done some work on converting some of the
>> extensions to the C++ native API. I don't think any of that would depend
>> on new code in the interpreter that won't go in 4.2.0, so I think it would
>> be nice to have those extensions updated with what is in trunk, rather that
>> what is in 4.1.3.
>>
>> --
>> Mark Miesfeld
>>
>>
>> On Wed, Nov 20, 2013 at 6:07 AM, Mark Miesfeld <[email protected]>wrote:
>>
>>> I thought I did, let me see what I can find.
>>>
>>> --
>>> Mark Miesfeld
>>>
>>>
>>> On Wed, Nov 20, 2013 at 5:42 AM, Rick McGuire <[email protected]>wrote:
>>>
>>>> Mark,
>>>>
>>>> Have you written down any notes on what files need to be updated when
>>>> we create a new release branch? It's been a while since I've done one.
>>>>
>>>> Rick
>>>>
>>>>
>>>> On Wed, Nov 20, 2013 at 7:50 AM, Mark Miesfeld <[email protected]>wrote:
>>>>
>>>>> Rick,
>>>>>
>>>>> I'm so glad you brought this up. I've been meaning for a couple of
>>>>> months to start an e-mail with the title: "Discuss: what should be due
>>>>> with
>>>>> trunk?"
>>>>>
>>>>> Of the several different possibilities, which path to take were
>>>>> somewhat dependent on how you felt. The 2 foremost in my mind were
>>>>> exactly
>>>>> what you are suggesting, or to branch off trunk to a "holding" directory
>>>>> like we did with some of your 4.0 work that you didn't want to lose and
>>>>> branch 4.1.3 to 4.2.0.
>>>>>
>>>>> I think your proposal is ideal, I'm all for it.
>>>>>
>>>>> --
>>>>> Mark Miesfeld
>>>>>
>>>>>
>>>>> On Wed, Nov 20, 2013 at 4:30 AM, Rick McGuire
>>>>> <[email protected]>wrote:
>>>>>
>>>>>> The code in trunk is not quite to a point where all of the new
>>>>>> features are ready to go. In particular, the stackframe/exception stuff
>>>>>> is
>>>>>> a long way from being complete. This unfortunately, is also blocking
>>>>>> shipment of some useful new features that are not dependent upon this
>>>>>> other
>>>>>> work.
>>>>>>
>>>>>> I'm not really sure when the exception stuff will be ready, there's a
>>>>>> lot of work still needed and frankly, I'm at a point where I've been
>>>>>> stuck
>>>>>> on what direction some things should go with that. I suspect it might be
>>>>>> better at this point to back off a touch and first ship a smaller subset
>>>>>> of
>>>>>> what's there.
>>>>>>
>>>>>> Anyway, I'm thinking we might want to push the current trunk up to
>>>>>> 4.3.0, create a 4.2.0 branch off of 4.1.3 and merge in as many of the new
>>>>>> RFEs as we can. There are also a number of open RFEs that are pretty
>>>>>> small
>>>>>> that we could get off of our plates easily.
>>>>>>
>>>>>> I think I might be able to start working on getting the branches
>>>>>> created for the code, docs, and test suite and start doing the merges.
>>>>>> Do
>>>>>> others think this is a good idea?
>>>>>>
>>>>>> Rick
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Shape the Mobile Experience: Free Subscription
>>>>>> Software experts and developers: Be at the forefront of tech
>>>>>> innovation.
>>>>>> Intel(R) Software Adrenaline delivers strategic insight and
>>>>>> game-changing
>>>>>> conversations that shape the rapidly evolving mobile landscape. Sign
>>>>>> up now.
>>>>>>
>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>>>>>> _______________________________________________
>>>>>> Oorexx-devel mailing list
>>>>>> [email protected]
>>>>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Shape the Mobile Experience: Free Subscription
>>>>> Software experts and developers: Be at the forefront of tech
>>>>> innovation.
>>>>> Intel(R) Software Adrenaline delivers strategic insight and
>>>>> game-changing
>>>>> conversations that shape the rapidly evolving mobile landscape. Sign
>>>>> up now.
>>>>>
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>>>>> _______________________________________________
>>>>> Oorexx-devel mailing list
>>>>> [email protected]
>>>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>>>>
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Shape the Mobile Experience: Free Subscription
>>>> Software experts and developers: Be at the forefront of tech innovation.
>>>> Intel(R) Software Adrenaline delivers strategic insight and
>>>> game-changing
>>>> conversations that shape the rapidly evolving mobile landscape. Sign up
>>>> now.
>>>>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>>>> _______________________________________________
>>>> Oorexx-devel mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>>>
>>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Shape the Mobile Experience: Free Subscription
>> Software experts and developers: Be at the forefront of tech innovation.
>> Intel(R) Software Adrenaline delivers strategic insight and game-changing
>> conversations that shape the rapidly evolving mobile landscape. Sign up
>> now.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Oorexx-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
>>
>
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
