Tomas:
>That said, I'd like to take the opportunity to vent something that has
been
>nagging me for a while
An excellent description of your frustration, Tomas. I think it is
important for the users of a system to explain to its creators what is
bothering them. I want to make a couple of comments, but I want to stress
first that I understand and even agree with many of your comments, and I
don't want to imply that you shouldn't have made them...
>All the continuous NAnt restructuring...
>I'm going to be brutally honest here: Even though no 1.0 release of nant
has
>ever been done, it has been used by people to build *real* systems for a
>really long time now.
As you say, NAnt is not yet at 1.0, isn't it an unrealistic expectation of
us early adopters to use a pre-1.0 release and constrain its developers not
to change the system radically as they learn new things in order to get the
product to 1.0?
>My big point is that many of the changes were done with little or no
regard
>to the impact they might have on code outside the actual nant code base,
and
>that's a problem now. One I personally consider a serious one.
Again pre-1.0, an extension mechanism and general architecture that works
well, is clear and is maintainable outweighs backward compatibility IMO. As
an early adopter (who has written custom tasks as well) I fully expect
this. Further, I also know that I don't *have* to upgrade. If I have that
software working on a real project, I can use that version, migrating my
tasks (if they are generic enough for reuse) at a later date, when the
architecture stabilizes (which I would expect in the 1.0 version of NAnt).
>If you want people to use nant effectively, and be able to take advantage
of
>what new builds of Nant offers easily, you need to start taking into
>consideration just how easy is going to migrate to a new build, and that
>takes far more than simply ensuring the .build files are valid.
Again, after the 1.0 release, I would agree with this. But prior to that,
ease of use, and adoption are IMHO more important goals. NAnt has the
potential to be *the* definitive build tool for the .NET platform, but it
won't be if it isn't as easy to use, understand, and install as possible.
Constraining these with backward compatibility issues before the 1.0
release will make this a lot less likely to happen.
NAnt has a much bigger hill to climb than Ant ever did to become a standard
in the MS world. We at ThoughtWorks are engaged with clients who are
looking for build solutions for .NET, and we are pushing NAnt as the answer
to their needs. Right now the biggest barrier to adoption are things like
the NAntContrib problem, the ease of use of VS -- not backward
compatibility. Some of them want to see a 1.0 version before they will
adopt. All of them want a simple turnkey installation, and a clear
architecture. Finding the best solution to NAnt's architectural and
deployment needs IMO outweighs backward compatibility at this time if NAnt
is going to have wide appeal in the VS-dominated world of the MS shops out
there. I would rather see radical changes in the code base as the NAnt
developers improve the design, than see them stop short of optimal in the
name of backward compatibility for what test versions of the code base
(which is clear by the lack of 1.0 designation, and the attitude of the
project members).
Best,
Bill
William E. Caputo
ThoughtWorks, Inc.
--------
"Its the foolish cat that looks at the finger when it is pointing at the
food"
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
