Roadplan for CruiseControl.NET

[savornicesei]

Hi @RubenWillems, @obones
Based on your discussion, I would love to continue the discussion where CC.NET could go given the current state of the development tools and the advent of CI/CD.

Some questions that I have:

1. What's the relation with ThoughtWorks ? Even the license is not a well-known OSS license but a "ThoughtWorks Open Source Software License".
2. Can the license be changed to MIT/ Apache 2.0? I think agreement from all contributors is needed.
3. How come the latest releases (up to 1.8.5) and release tags are missing from GitHub?
4. There are pull requests waiting to be incorporated in the code base. It would be nice to do a new CC.NET release
5. We could configure CC.NET to be automatically build in appveyor / travis. No need for additional infrastructure except GitHub and its OSS-friendly (aka free) ecosystem
6. The UI is sooo static
7. The build log is sooo hard to follow (perhaps there's an xslt template for pretty view)

I'm more familiar with Jenkins. The current project I'm working on is using svn and CC.NET but the plan is to move to Git and Bamboo as CI server.
But as a .NET developer (and a linux user) I would love to have more CI-related tools build in .NET instead of java (like Jenkins, Bamboo, SonarQube, Nexus).

Best,
Simo

[RubenWillems]

Hi As far as I can remember, there is no problem going to MIT license, the relation with Thoughtworks is in fact cut. About the pull requests, that can be done. I need to check if they are on the 1.8.5 release, or on the 1.9 Maybe we should clean up the 1.9 release, there are some unfinished items there. About the automatic building, if you could provide a link or documentation on how to do it, that would speed up the process. What's the problem with the build log? I used it for many years, and you can easily use xslt to transform it to a nice view. ° one for the unit tests ° one for the build ° ... So I do not see what makes it hard to read the build log in your system. If you want, you may private mail me with a build log, so I can take a look at it. (remove paswords and the like) and tell me what you would like to have. The UI .... That's indeed static, and web development has changed a LOT in the past years. I'm a bit scared of tackling the web UI, because that would mean a total re-write. Now it is indeed static, but also very basic. Anyone with a bit of web experience can make minor adjustments. What would we choose for the 'engine' ? ° asp mvc ° asp core ° ... many things to decide, and I have no real experience in web development, changing an existing program is totally different than setting one up from scratch with a good architecture. I know there is a lot of code in the web ui, that can be ditched, because that functionality is now standard. ° objection --> Ninject ° asp handlers --> asp.net core ° .... I would like to change it to .Net core, as that would mean Linux is easily supported. Dropping the windows specific items (registry and the like) should not pose a real problem I think. Only the windows service part should have a linux daemon. I do not know if that can be done in the same project. If there some people helping, this is a good way foreward, but I'm not doing this alone ;-) any thoughts / tips are welcome. with kind regards Ruben Willems

…

On Fri, 19 Apr 2019 at 10:55, Simona Avornicesei ***@***.***> wrote: Hi @RubenWillems <https://github.com/RubenWillems>, @obones <https://github.com/obones> Based on your discussion <#263 (comment)>, I would love to continue the discussion where CC.NET could go given the current state of the development tools and the advent of CI/CD. Some questions that I have: 1. What's the relation with ThoughtWorks ? Even the license is not a well-known OSS license but a "ThoughtWorks Open Source Software License". 2. Can the license be changed to MIT/ Apache 2.0? I think agreement from all contributors is needed. 3. There are pull requests waiting to be incorporated in the code base. It would be nice to do a new CC.NET release 4. We could configure CC.NET to be automatically build in appveyor / travis. No need for additional infrastructure except GitHub and its OSS-friendly (aka free) ecosystem 5. The UI is sooo static 6. The build log is sooo hard to follow (perhaps there's an xslt template for pretty view) I'm more familiar with Jenkins. The current project I'm working on is using svn and CC.NET but the plan is to move to Git and Bamboo as CI server. But as a .NET developer (and a linux user) I would love to have more CI-related tools build in .NET instead of java (like Jenkins, Bamboo, SonarQube, Nexus). Best, Simo — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#264>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEUZAIBP6SL2DVCKXXEU2TPRGCINANCNFSM4HHC4XHA> .

[savornicesei]

Hi @RubenWillems

1.9 release

It was stated in the 1.8.5 release that the next will be 1.9 but ...
Where is the 1.9 branch? Currently there's no 1.9 branch in GH and quite a lot of differences between 1.8 branch and master. The tags also stop at ccnet_1_4_5_CTP.
I suppose the branching strategy in SVN was to create a next-release branch and work on it.
On git, we should have the master as the main development line - containing only finished features. Is it possible to acomplish this for 1.9? or just release 1.9 from its svn branch?

vNext release (2.0)

This should bring .NET Core 3.0 to the table and any other unfinished feature still lingering around.
Plus:

• MIT license or Apache 2.0 - signoff from all contributors I think is needed
• change ThoughtWorks namespaces to ... ccnet!?! CruiseControlNet?
• cleanup code (remove obsolete fields, unused code, commented code, etc)
• evaluate if it's worth switching from Sandcastle to DocFx
• Include Sandcastle documentation to main site
• some new UI prototype that works side by side with the existing one
  • brainstorming resulting in mockups
  • we can inspire from Jenkins that slowly introduced their new UI redesign called Ocean Blue (supporting pipelines)
  • decide on a front-end library: Angular, react, vue,
• replace Gendarme with Roslyn
• ....

Next steps (IMHO)

• decide branching strategy (can we merge 1.9 in master? Can we take out unfinished features from master? Or better work on 1.9 branch, release it and then merge it to master ?)

• make it build

• replace all build scripts with a cake one (that's also cross platform)

• use GitVersion for versioning

• Add TravisCI and AppVeyor ci scripts for master branch (and 1.9 if needed)

• Have AppVeyor publish nightly builds to JFrog bintray or any other hosting with free plan for OSS projects. Perhaps SourceForge? Or?

• update tools, especially NAnt to 0.92 + contrib extension (there are some goodies there for .NET projects)

• Decide what pull-requests to be merged into 1.9. There is a PR targeting 1.6 but most of them are targeting master and several are targeting 1.8

• update to .NET 4.5

• use libraries from NuGet instead of \lib folder if possible

• Cleanup documentation and migrate it to jekyll site that's supported by GitHub Pages. Perhaps move it to a gh-pages branch?

• Extract confluence.public.thoughtworks.org pages from internet archive and add relevant content to current documentation

Misc

Do you still have a backup of the old site (running on ChilliProject)? I'm more interested in the list of tickets and their status, including feature requests.
Is it possible to have the SVN still available in sourceforge but in read-only mode? And a note on the site's frontend that it moved to github? Again, it would he helpful to get a copy of the old SVN repository.

Best,
Simo

[mintsoft]

Just to chime in here, I think all of those look like steps that are worth taking. I'd suggest that for 1.9 it'd make the most sense to base it on master. I use a fork of ccnet with a few additions built from master and it's absolutely fine. I don't think there's any regressions that I've come across vs 1.8.5 that would preclude it from being regarded as stable enough for release.

[mintsoft]

In that light, I think it might be worth cherry picking a few high value PR's:

• Fix powershell args: Powershell -file doesn't handle arguments that are string[]  #260 or The PowerShell task passes list arguments as a single parameter #255
• NUnit U/G: Change NUnit v2 to v3 #259
• HG: SourceControl/Mercurial: hg heads on a single branch (fix #281) #251
• Mono compatibility: FileTaskResult.ReadFileContents() should not use MemoryFailPoint on L… #342 #226

[savornicesei]

@mintsoft Let's not forget git ones: #206, #254, #258. For #163 - a decision is required.

Perhaps it will be easier to merge all on master, stabilize it and release 1.9 from it.

Digging through web archive seems like the project switched several systems until landing on GitHub that's why there are PRs but no tickets related to them. I would really like to know what tickets were left behind. Or just recreate/import them here, on GH.

[mintsoft]

Perhaps it will be easier to merge all on master, stabilize it and release 1.9 from it.

Yeah I think that's definitely the easiest approach

[RubenWillems]

The master branch contains the code for 1.9.

In the past we developped in the main branch, and when we decided that all features where done for a release, we made a release specific branch. From that point on, only bugfixes and small tweaks like UI were done in that branch, and ported back to the main. Development could continue in the main branch of course.
I see a there seems to be intrest in a new release, the question will be what items would be included?
if they are not breaking with 1.8.5 we could make them in the 1.8 branch and release 1.8.6.
For all the other stuff, like build on Linux, use .Net core, I would place those in the main branch, and when things look ready, we can decide when to make a branch for 2.0. The 1.9 can be a nightly build range.
Or we can leave the 1.8 as is, clean up the 1.9 branch (basically revert to 1.8.5 I think) and merge in the most wanted items. That way there is not a problem with compatibility. And when 1.9 is out, do all the core rework (making a 1.9 branch for bugfixing)
I personally prefer cleaning up the main / 1.9 branch, and merge the most wanted items in there.

[RubenWillems]

There 2 new projects added one for the 1.9 release and one for the 2.0 release.
As suggested a 1.9 release with the most wanted improvements,
and a 2.0 for the major rework.
Any commnents are welcome.

[RubenWillems]

I'm trying to port CCNet to .NEt Core.
Stuff done so far :
° netreflector + tests
° CCNet
* Objection + tests
* Remote (dropped the remoting part because that does not exist in .Net Core)

Now the problem starts with the tests, because we used various mocking libraries
through the years :-(

Questions :
° should we still use mocking libraries, or do we write our own fakes ?
this ensures that we do not have this problem again in the future,
but it can be a lot of work
° if we use a mocking library, which one?
the only one I could find after a quick search was : MOQ
https://github.com/moq/moq
I never used it though
--> learning this library can also be a lot of work

any preferences ?

any second thoughts, suggestions

[obones]

Here at work, we are using MOQ 4.10 (https://github.com/moq/moq4) with .Net Core, so I would feel right at home.