← Back to team overview

nunit-core team mailing list archive

Re: Status of Development

 

Hi Charlie,

> Hi Andreas,
> 
>> I worked on the installer and it can install the framework. 
>> It still needs integration into the build script (target and 
>> staging directory) and work needs to be done for integrating 
>> the builds for .NET 3.5 and .NET 4.0.
> 
> I think we can call it finished. There are a lot of initial 
> things like this which will never be finished if we wait for
> each feature to be added. In fact the Nant script is in that
> state now. I plan to clean it up and get it done.
> 
> I have some questions about the installer, which could lead
> to change:
> 
> 1. Should it really be putting the framework in the GAC,
> even as an option? I notice that you cannot manually remove
> an assembly from the GAC if it's marked as required by an
> installed application.

We discussed this on the nunit-discuss list. I think we decided to make
it optional to put the framework in the GAC. Removing the option would
make the installer code simpler which is a good thing.

If it could lead to troubles with removing the framework from the GAC
I'd agree with removing the option and not installing the framework in
the GAC.


> 2. Do we need it at all? I know, I know, I am the one who
> listed it. :-) But now I wonder: Should we have an msi for
> the framework, another for the gui, etc. Or should we just
> have a single installer that combines them all, in a separate
> project on Launchpad? That would leave the individual
> projects to be xcopy-deployed only.
> 
> What do you think? If you want to initiate some sort of 
> discussion of this, nunit-discuss would be a good place,
> since both items impact users as well as developers.

I think that we wanted to create the framework installer because we
thought that it would be easier for beginners. Maybe we should discuss
this at nunit-discuss first.


>> I'm working on the blueprint for the console-runner. BTW, 
>> what is the priority of the console-runner? What does series 
>> mean? Is this always trunk for us? What's the milestone 
>> target for the console-runner?
> 
> Series | Branch | Trunk are concepts on Launchpad that we
> can map in varius ways. I used the most common approach:
> 
> Series is one main release, with it's pre-releases and 
> bug fix releases after the fact.
> 
> You get one branch per series, so it's basically the same
> except that you can have branches that are not part of 
> a series. I think those will be mostly owned by individuals.
> 
> Assigning a blueprint to a series and milestone is a function
> of a release manager. We can do it in advance or at the last
> minute.  
> 
> Everything we are so far doing is trunk, because I decided
> not to have any other series until we are closer to a true
> release of 3.0. Then we will have a 3.0 series. At first
> I had a 2.9 series, but talking with Paul Hummer about it
> I realized that it has no particular purpose. I plan to
> do releases of whatever is ready at each milestone in
> addition to the key items already noted. So far, I only
> made assignments to two milestones, 2.9.1 and 2.9.2. You
> can call the first NUnit 2.5 Reborn and the second NUnit
> With NUnitLite.

OK, I see.

> Remember that you know as much as I do about Launchpad,
> so if you see a better way let me know.

I'm not sure about that. I suppose that in the meantime you know more
about Launchpad. :-)

> 
> Regarding console-runner, I'm pretty sure it should be
> a separate project, which would have it's own series,
> branches, milestones and releases. What do you think?

I suppose that the gui-runner will be a separate project. And the
console-runner is not coupled to a specific framework version. Maybe it
should be a separate project.


>> I'll start drafting the blueprint for the Linux Makefile. If 
>> I understand correctly, the goal is that "configure", "make", 
>> "make install" will work, isn't it?
> 
> Yes. And maybe two of them...
> 
> 1. That accompanies the source code actually builds first,
> using NAnt to do it.
> 
> 2. Another that accompanies binary distros would probably
> just copy them to the right place.
> 
> This is just my guess. We need to do what Linux people
> expect to have done - whatever that is. :-)

I'll do a research and write a spec for that.

Andreas

> 
> Charlie




References