On Wed, Sep 1, 2010 at 12:29 PM, Rick McGuire <object.r...@gmail.com> wrote:
> That would work too, although I think if there are new APIs included,
> then the version number should be 4.1.0, not 4.0.2.

Oh, yeah.  I'm not set on a version number.  4.1.0 would be fine.

--
Mark Miesfeld

> Rick
>
> On Wed, Sep 1, 2010 at 3:22 PM, Mark Miesfeld <miesf...@gmail.com> wrote:
>> On Wed, Sep 1, 2010 at 11:32 AM, Rick McGuire <object.r...@gmail.com> wrote:
>>
>>> I wonder if we could include your new ooDialog work in the new release
>>> and make it the 4.1.0 version?  There are a couple of new APIs that we
>>> added to support that, but I suspect it would not be difficult to
>>> back-port those changes to a 4.0.1 base.  It would be nice to get all
>>> of that work out if you think it's ready for primetime.
>>
>> The problem is, I'm not sure that it is ready for prime time.  In
>> particular, the new documentation that I started, will take me some
>> time to finish.  And I'm worried about backwards compatiblity.  My
>> tests look good, but I constantly find things that other people's
>> programs do that I never imagined people would do.  For instance,
>> invoking methods on a subclass object in init() before the superclass
>> is initialized.
>>
>> What I would really like to do, <grin>, is back-port the couple of new
>> APIs to a 4.0.1 base, release it as 4.0.2, and add a separate beta
>> ooDialog that could be downloaded from SourceForge.
>>
>> The beta ooDialog could replace the 4.0.2 release ooDialog by swapping
>> the oodialog.dll and ood*cls files.  (I was thinking of writing a
>> simple installer that would do the swapping for the user and allow
>> swapping back.)
>>
>> Your objection to back-porting those couple of new APIs to 4.0.1 was
>> that they weren't documented.  So, I was going to try and overcome
>> that objection by doing the documentation myself.  <grin>
>>
>> My motivation for this was the, perhaps forlorn, hope that enough
>> users would work with the beta ooDialog to give feedback on the new
>> classes and new methods before they were set in stone.  And find
>> backwards compatibility issues, that could maybe be worked out.
>>
>> --
>> Mark Miesfeld
>>
>> ------------------------------------------------------------------------------
>> This SF.net Dev2Dev email is sponsored by:
>>
>> Show off your parallel programming skills.
>> Enter the Intel(R) Threading Challenge 2010.
>> http://p.sf.net/sfu/intel-thread-sfd
>> _______________________________________________
>> Oorexx-devel mailing list
>> Oorexx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Reply via email to