Re: [Nmock-general] What shall we do for the next version

[Joe W. <jo...@tr...>]

I'm okay with breaking backwards compatability, *so long* as we do it in 
a way that allows the old api and new api to be used in parallel. This 
means allowing one test at a time to be migrated and for users to 'test 
the water' with the new API, before committing to changing their 
existing code.

This rules options 1, 3 and 4 out totally for me, leaving the only 
option as calling the new package NMock2 (or something else new), which 
I have no issue with.

Another option to add:

5) We add some methods to the new Mock class that give the API the same 
methods as those in the original library, which merely act as adaptors 
to the new API and are marked as obsolete. This allows the new library 
to be dropped in as a replacement to the old one, providing new 
capabilities to the Mock class, whilst allowing old code to still work.

Not sure how feasible this is and it would definetely require more effort.

class NMock.Mock:

    [Obsolete("Use Expects() instead")]
    public void Expect(string methodname, param object[] args)
    {
         Expects(Once()).Method(methodname).With(args);
    }


My vote is definetely for option 2. I think just calling the new library 
NMock2 and allowing users to use whichever they want (or both) will make 
life simpler for all.

-joe

Steve Freeman wrote:

> Here in NMock Castle, we're thinking about the next major version of 
> NMock. We intend to release a version based on our experience with 
> jMock  (http://www.jmock.org), which is a much cleaner structure but 
> is a significant change of API.
>
> The main issue at this point is how to manage the transition, in 
> particular the choice of namespace since NMock is taken with the 
> current library. There are some possibilities:
>
> 1) Package the current version in a strongly named assembly. Then the 
> version of NMock could be changed with each VS project, but all of a 
> project would have to be converted at once.
>
> 2) Call the new one NMock2. Personally I have problems with this 
> because:  I can't stand the cruft on the name especially when I 
> believe the new version represents the long-term approach; and, every 
> time we up the counter on the API, people will have to fix their tests 
> even if there's no other change.
>
> 3) Move the old one to NMock0, and have the current version as NMock. 
> Old code could be retrofitted with a 'using NMock0 as NMock' clause. 
> In theory, this could be extended indefinately using numbered versions 
> for deprecation.
>
> 4) Just get on with the new version and not care about the consequences.
>
> What's best for people. My only caveat is that I'd like to avoid the 
> old 'make' problem, where the confusion between tab and space was 
> perpetuated because they didn't want to annoy their (12) users at the 
> time...
>
> S.
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital 
> self defense, top technical experts, no vendor pitches, unmatched 
> networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Nmock-general mailing list
> Nmo...@li...
> https://lists.sourceforge.net/lists/listinfo/nmock-general
>