On 2011-08-12, Roy Chastain wrote:

>> Have you got an environment where you can build the 1.x and compact
>> framework assemblies (right now I don't)?

> I could at one point a few years back, but probably not now.

The same is true for my own environment.

> I was referring more to just being able to get the source from the
> tree.  (For me getting anything SubVersion related working is a BIG
> step). :-)

Congrats, then. 8-)

> That was part my question about duplicating effort.  If changes need
> to be made to get an environment that supports building, there is no
> need for multiple people to tackle it at once.

This is true, but at least for the next release we'll need one
accessible for the release manager.

> In the past I converted the zipped source to VS 2010 keeping the 2.0
> framework target and made that work, but I did not work on tests etc.,
> so I don't know how valid my efforts were.

So far I still don't want to use VS at all but stick with the NAnt
build.  I'm not familiar enough with the express editions - does anybody
know whether VS 2010 Express supports setting the compilation target to
2.0?  We can't expect contributors to own one of the non-free editions.

>> just as an alternative distribution in addition to one signed with
>> the new non-secret key?

> Yes, both versions.  I think that is necessary to keep the 3rd party
> people running until they have time to switch to the new non-secret key.

OK, then we agree.

>> Otherwise 1.2.11 is long overdue anyway

> Yes, I agree, that is way I was suggesting doing the "minimum" which is
> basically integrating the currently supplied/tested/gold fixes and
> features (such as the log file renaming feature-fix).  Feature requests
> and fixes that need work go into the 4.0 build tree (and the refactored
> 3.5 build tree which was my step 4).  This approach should allow for an
> "easy" (not hardly) production of the 1.2.11 that would be a drop in for
> anyone on 1.2.10 with the fixes/features that have been tested.

Yes.

> Maybe we have to revisit the bug/feature list and produce 1.2.12 with
> the next round before going on to 2.0 tree with less frameworks.  Once
> we do the 2.0 tree the 1.2.xx tree is frozen and we have less to
> maintain because we do not have to worry about 1.0, 1.1, compact etc.
> To sum up this paragraph, we produce a new stable long life span
> product (1.2.11 or 1.2.12) that people who do not wish to/cannot move
> forward can use for a long time to come.

Sounds good to me.

Stefan

Reply via email to