[Oorexx-devel] Thinking about a next release ...
Hi All, Thinking ahead to the next release ... I've finally finished up with everything I wanted for ooDialog, so it is ready to go into a regular beta / release cycle. In addition, Rick has done a lot with XML. I think those 2 extensions would make a good base for a next release. From watching the svn notices, I see a lot done with XMl, but I don't have any sense of how much work still needs to be done there. Coupled with this are two other things I'd like to do. 1.) I'd like to not go so long between releases, especially when we have some fixed bugs. 2.) I'd like to do releases of some of the extensions independent of the interpreter releases. So, I thought maybe we could kick it around a little and see what makes sense to do going forward. I see 3 possibilities for the ooDialog release I want to do: 1.) Put the current ooDialog stuff that is ready in the 4.1 fixes branch. Do a bug fix + ooDialog release with a beta starting in August. 2.) Do a release with ooDialog and XML as major enhancements. Start a beta around August if that's practical with the XML stuff. 3.) I can do an ooDialog only beta / release independent of the interpreter. ooDialog would have an installer that drops it into any 4.1.0 ooRexx installation. Liked to hear what people think. -- Mark Miesfeld -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Thinking about a next release ...
On Tue, Jul 10, 2012 at 11:50 AM, Mark Miesfeld miesf...@gmail.com wrote: Hi All, Thinking ahead to the next release ... I've finally finished up with everything I wanted for ooDialog, so it is ready to go into a regular beta / release cycle. In addition, Rick has done a lot with XML. I think those 2 extensions would make a good base for a next release. From watching the svn notices, I see a lot done with XMl, but I don't have any sense of how much work still needs to be done there. Quite a bit of work left to be honest. Still working my way through the various w3c specs making sure I've got good coverage, and there's a ton of tests that still need to be written, plus a big pile of documentation. Coupled with this are two other things I'd like to do. 1.) I'd like to not go so long between releases, especially when we have some fixed bugs. 2.) I'd like to do releases of some of the extensions independent of the interpreter releases. So, I thought maybe we could kick it around a little and see what makes sense to do going forward. I see 3 possibilities for the ooDialog release I want to do: 1.) Put the current ooDialog stuff that is ready in the 4.1 fixes branch. Do a bug fix + ooDialog release with a beta starting in August. Some of the stuff I've added to the trunk version is currently in a bit of a half-baked state. It's sort of the basis for implementing catch/finally blocks ala NetRexx, but there's a lot more work needed to take the next step. The trunk version could be used as a basis, but there are a few features that probably need to be buried under the covers in order for it to go out. Even if you base this on the 4.1 branch, it probably should be labeled the 4.2.0 release, with trunk then getting pushed to 4.3 If we're going to base this on the 4.1 branch, we should make a new 4.2 branch from that to use as the working version for the beta and keep the 4.1 branch just for bug fixes for 4.1 2.) Do a release with ooDialog and XML as major enhancements. Start a beta around August if that's practical with the XML stuff. I don't see August as a practical date for the XML stuff being ready. At this point, I'm not even sure if January is practical, given the amount of work still required. However, I've opened quite a few small RFEs recently based on things that have annoyed me while writing the XML support. I've just been opening those with the intent of returning to them once I've going the XML support a little further along. I could re-prioritize and see if I can knock off some of these. Most of these would be simple to implement (probably harder to write the tests and docs than the actual code). Maybe set a deadline of September. I'd actually like to use a few of those for the XML code, even though it means it would be tied to 4.2.0 release. Since it already uses 4.1-specific features, I guess that's not that big of a deal. 3.) I can do an ooDialog only beta / release independent of the interpreter. ooDialog would have an installer that drops it into any 4.1.0 ooRexx installation. I'm comfortable with that too. Rick Liked to hear what people think. -- Mark Miesfeld -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Thinking about a next release ...
It depends, Mark. Does the new ooDialog have any backward compatibility issues? Will anyone have to touch any of their existing ooDialog routines just because they need a particular bugfix in ooRexx? If so, option 3 is preferable. Keep them separate, so a user can get the latest bugfixes without having to commit also to changing their ooDialog stuff. If not, option 1 is preferable because it provides a tangible and attractive hook to draw attention to the latest ooRexx release. I would leave the XML update for a later release. It's always nice to have some sort of tantalizing new functionality to point to, rather than just a bugfix release. IMHO, of course, -Chip- On 7/10/2012 3:50 PM Mark Miesfeld said: Hi All, Thinking ahead to the next release ... I've finally finished up with everything I wanted for ooDialog, so it is ready to go into a regular beta / release cycle. In addition, Rick has done a lot with XML. I think those 2 extensions would make a good base for a next release. From watching the svn notices, I see a lot done with XMl, but I don't have any sense of how much work still needs to be done there. Coupled with this are two other things I'd like to do. 1.) I'd like to not go so long between releases, especially when we have some fixed bugs. 2.) I'd like to do releases of some of the extensions independent of the interpreter releases. So, I thought maybe we could kick it around a little and see what makes sense to do going forward. I see 3 possibilities for the ooDialog release I want to do: 1.) Put the current ooDialog stuff that is ready in the 4.1 fixes branch. Do a bug fix + ooDialog release with a beta starting in August. 2.) Do a release with ooDialog and XML as major enhancements. Start a beta around August if that's practical with the XML stuff. 3.) I can do an ooDialog only beta / release independent of the interpreter. ooDialog would have an installer that drops it into any 4.1.0 ooRexx installation. Liked to hear what people think. -- Mark Miesfeld -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Thinking about a next release ...
On Tue, Jul 10, 2012 at 9:10 AM, Rick McGuire object.r...@gmail.com wrote: On Tue, Jul 10, 2012 at 11:50 AM, Mark Miesfeld miesf...@gmail.com wrote: Hi All, Thinking ahead to the next release ... 1.) Put the current ooDialog stuff that is ready in the 4.1 fixes branch. Do a bug fix + ooDialog release with a beta starting in August. Some of the stuff I've added to the trunk version is currently in a bit of a half-baked state. It's sort of the basis for implementing catch/finally blocks ala NetRexx, but there's a lot more work needed to take the next step. The trunk version could be used as a basis, but there are a few features that probably need to be buried under the covers in order for it to go out. Even if you base this on the 4.1 branch, it probably should be labeled the 4.2.0 release, with trunk then getting pushed to 4.3 I was thinking more along those lines. Push trunk to 4.3, branch the current 4.1 to 4.2. Base a 4.2.0 release on 4.2. That would leave a 4.2 branch for bug fixes. Would we still need a 4.1 branch? The 4.2 branch would essentially be the 4.1 fixes branch with just a version bump, 4.1 to 4.2. 2.) Do a release with ooDialog and XML as major enhancements. Start a beta around August if that's practical with the XML stuff. I don't see August as a practical date for the XML stuff being ready. At this point, I'm not even sure if January is practical, given the amount of work still required. However, I've opened quite a few small RFEs recently based on things that have annoyed me while writing the XML support. I've just been opening those with the intent of returning to them once I've going the XML support a little further along. I could re-prioritize and see if I can knock off some of these. Most of these would be simple to implement (probably harder to write the tests and docs than the actual code). Maybe set a deadline of September. I'd actually like to use a few of those for the XML code, even though it means it would be tied to 4.2.0 release. Since it already uses 4.1-specific features, I guess that's not that big of a deal. Maybe, do a 4.2.0 release based on my #1 option in August. Then do a next release around a January time frame that would have XML and / or the small RFEs. This would fit in with my desire to do at least 2 or 3 smaller releases per year so that fixed bugs get picked up sooner. 3.) I can do an ooDialog only beta / release independent of the interpreter. ooDialog would have an installer that drops it into any 4.1.0 ooRexx installation. I'm comfortable with that too. Yeah, I am too. So, I'd like to go with #1 or #3 and plan on a next release around Jan 1 time frame to pick up Rick's new stuff. -- Mark Miesfeld -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Thinking about a next release ...
On Tue, Jul 10, 2012 at 9:44 AM, Rick McGuire object.r...@gmail.com wrote: On Tue, Jul 10, 2012 at 12:35 PM, Mark Miesfeld miesf...@gmail.com wrote: 3.) I can do an ooDialog only beta / release independent of the interpreter. ooDialog would have an installer that drops it into any 4.1.0 ooRexx installation. I'm comfortable with that too. The more I think of this, the more I think I'm in favor of option #3 if the only change is the ooDialog support. Since this is a windows only update, we'd either only created the new version for Windows, which would create confusion, or end up creating a new release for all platforms where the only change would be the update version numbers. To go with #1, we should have at least some platform-independent enhancements. Okay, that's what I'll do. Right now there's really only 1 bug that I'm thinking about, which is the HostEMU bug. I know several people that ran into that. -- Mark Miesfeld -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Thinking about a next release ...
On Tue, Jul 10, 2012 at 12:52 PM, Mark Miesfeld miesf...@gmail.com wrote: On Tue, Jul 10, 2012 at 9:44 AM, Rick McGuire object.r...@gmail.com wrote: On Tue, Jul 10, 2012 at 12:35 PM, Mark Miesfeld miesf...@gmail.com wrote: 3.) I can do an ooDialog only beta / release independent of the interpreter. ooDialog would have an installer that drops it into any 4.1.0 ooRexx installation. I'm comfortable with that too. The more I think of this, the more I think I'm in favor of option #3 if the only change is the ooDialog support. Since this is a windows only update, we'd either only created the new version for Windows, which would create confusion, or end up creating a new release for all platforms where the only change would be the update version numbers. To go with #1, we should have at least some platform-independent enhancements. Okay, that's what I'll do. Right now there's really only 1 bug that I'm thinking about, which is the HostEMU bug. I know several people that ran into that. We do have a number of bug fixes in the 4.1 branch. Maybe we could also do a bug fix release in conjunction with the ooDialog release. I've got a few open bugs I've opened recently, which I suspect I could have fixed by August. Rick -- Mark Miesfeld -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Thinking about a next release ...
On Tue, Jul 10, 2012 at 9:25 AM, Chip Davis c...@aviatrexx.com wrote: Does the new ooDialog have any backward compatibility issues? That's the big question. I've tried very hard to not break backward compatibility. But ... There are 2 areas. One is that there are a few methods that in the ooDialog doc were labeled as internal use only. If people used those internal use only methods, they might have a problem. The second area is something that I might have missed in my testing. Will anyone have to touch any of their existing ooDialog routines just because they need a particular bugfix in ooRexx? If so, option 3 is preferable. Keep them separate, so a user can get the latest bugfixes without having to commit also to changing their ooDialog stuff. I intend to have / will have separate ooDialog installs. So that if someone updates their ooRexx to, let's say 4.2.0, they can drop ooDialog 4.1.0 back in. In addition, I intend to keep the switchOODialog functionality so that people who install that, can switch between 4.1.0 and 4.2.0 versions of ooDialog. So, anyone using ooDialog in any of the current 4.x ooRexx releases, can stay with that ooDialog as long as they like on into the future. If not, option 1 is preferable because it provides a tangible and attractive hook to draw attention to the latest ooRexx release. I would leave the XML update for a later release. It's always nice to have some sort of tantalizing new functionality to point to, rather than just a bugfix release. Yeah, it looks like that's what we'll go with. I'll do an ooDialog only release now and bring in XML and probably a few other enhancements for the new year. IMHO, of course, It may be humble, but I'm glad you voiced it. -- Mark Miesfeld -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] [ oorexx-Bugs-3542187 ] Stackspace check on 64-bit platform not large enough
I ran into the problem today because of a small bug in a program I was working on. It appears we're not leaving enough stack space to be able process the error message for this condition. I ran into this on a 64-bit Windows platform, so I think this might be a 64-bit problem. Windows and *ix use different values for the minimum stack space and I suspect we need to bump this value for the 64-bit builds. It would be useful if people could run the following program on as many platforms as possible and report if the interpreter crashes: call recurse ::routine recurse call recurse Please update the bug report for any platforms where this crashes. I'll be able to test this on a 32-bit Windows built as soon as I get a new build finished on my other machine. Note, this is not a trunk issue, I was able to reproduce the problem on the 4.1 branch. Rick -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
