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

[Owen R. <OR...@th...>]

hi steve,
contrary to what i said before, i agree that using a NMock2 
namespace/assembly is not such a great idea.  that said, my main 
considerations are:
1) i would like to be able to migrate to the new apis gradually
2) i would like to be able to continue to support and enhance the existing 
api

of the four options, i prefer option number 4.  maybe we are worrying 
unnecessarily about the scope of the changes required by introducing the 
jMock-style apis.  presumably, we will still continue to use the majority 
of the IL generation code.  it is only the Method/Constraint classes that 
will be affected??  are there any strenuous objects to the jMock-style api 
classes and the original NMock classes living side-by-side in the same 
folder?

however, if this is too hard, we could do a complete branch and set up a 
new CVS module and build the new code into a separate assembly.  the new 
code could live in the NMock namespace -- namespace conflicts are only a 
problem if the new code uses classes that have the same name as the ones 
in the old assembly, and as the new jmock-style classes don't have a 
DynamicMock class (AFAIK) then conflicts should be minimised -- it will 
probably only be with the Constraint classes.

cheers,
owen.

---
R. Owen Rogers
ThoughtWorks Technologies (India) Pvt Ltd.

ThoughtWorks - Deliver with passion!

ThoughtWorks is always looking for talented people who are passionate 
about technology.  To find out more about a career at ThoughtWorks go to 
http://www.thoughtworks.com/career/.




Steve Freeman <st...@m3...>
Sent by: nmo...@li...
03/07/2004 03:12
 
        To:     nmo...@li...
        cc: 
        Subject:        [Nmock-general] What shall we do for the next 
version


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:

- 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.

- 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.

- 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.

- 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