Rubberduck 2.X/3.0 Backlog

[ThunderFrame]

This is a placeholder issue for adding backlog items/features. Add wishlist items at your peril....

I'm assigning numbers so we can identify them.

Here's a few to kick off....

001 - Parse Trees
002 - Plug-in architecture for host-specific magic
003 - Read the VBA storages and streams
004 - Deep inspections
005 - A better Object Browser
006 - A better Properties Window
007 - Inject our own editor windows
008 - Color schemes
009 - Access Forms and Reports
010 - Pretty printer
011 - Execution analysis tree
012 - Edit parse trees directly in refactorings, and update modules once

[grleachman]

IS there an option to load different sourcecontrol plug ins

[Hosch250]

Nope. We basically wrap a Git implementation and call it from our UI.

[retailcoder]

@grleachman I was chatting with @ThunderFrame yesterday, and I think it would be nice if we would just rewrite the composition root code and _really_ split things up - a plug-in architecture would allow us to implement host-specific needs into host-specific plug-ins... which solves quite a lot of problems.

So we'd have Rubberduck.Extensions.MicrosoftExcelHost.dll, Rubberduck.Extensions.MicrosoftAccessHost.dll, Rubberduck.Extensions.MicrosoftWordHost.dll, Rubberduck.Extensions.MicrosoftOutlookHost.dll, Rubberduck.Extensions.AutoCADHost.dll, etc. And of course Rubberduck.Extensions.Core.dll, which contains base types and interfaces, and heck, move the "default" implementation

Rubberduck.SourceControl.dll is its own separate assembly already; the dependency on LibGit2Sharp needs to be severed and moved to Rubberduck.SourceControl.Extensions.Git.dll.

If we make a nice framework to work with, extending Rubberduck with custom behavior and host-specific inspections and document-resolver strategies and whatnot, would ultimately make Rubberduck more flexible. People could chime in with "inspection packs", or... alternate source control providers. Seems like a lot of work though, but the result would be fun to extend.. and should leave Rubberduck more robust and, well, extensible.

We're not quite there yet though. Perhaps a 3.0 thing?

[ThunderFrame]

Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.

[PeterMTaylor]

Sounds and looks good from a planning ahead for next release point of view (sorry just myself talking)
So we are in a sense preparing for the next "Sprint!" after v2.0
I note that code metrics and reporting discussed previously are a lower priority in the backlog til after v3.0 -> actually this is a good idea until after an improved architecture is in place to see what works if this idea gains strength.

Just one "little bitty" question I need to ask about SourceControl. Do we know now (otherwise I'll ask again later when we gain more time/experience about it) if SourceControl via RD has an ability to do versioning of various objects such as _.bas/_.cls/*.frm into Git and back again via VBE?

Ta, Peter.

[grleachman]

I'd say v3 would be an epic... and you break that down into several sprints.

I'm very much into plugins and turning RubberDuck into a framework...
so providing an interface for SourceControl use and a default Git plugin : yes definitely up my ally
@PeterMTaylor I find it ironic that Rubberduck was born from a unittesting framework idea, yet there is so little unit testing and TDD is practically none existent. It would be really good to focus strongly on peer reviews and imbed testing into commits... An edict of "A push won't get accepted if it doesn't add appropriate Tests." probably won't go down well, but perhaps it will? Any views?

[Vogel612]

@grleachman that seems like a very meta discussion. I daresay opening the discussion and making a case for it is better off in chat or a separate issue. As I understood this issue is intended for the features themselves, and not about the process of implementing them. For the record: I like the idea :+1:

[ghost]

What's an execution analysis tree?

[retailcoder]

_that seems like a very meta discussion_

@Vogel612 that's why I tagged this issue with [meta] and [discussion] ;-)

@PeterMTaylor re: source control - that has shipped already, with 2.0 alpha/preview release. We also export the code from document modules, but for technical reasons we can't have sheet controls and other document-module stuff exported like the rest... for now.

@grleachman agreed, and this irony is beginning to become quite heavy and annoying. OTOH the code base only became as testable as it is now (we can say that, right?) with the architectural changes that occurred between 1.4.3 and 2.0; we'll catch up. Eventually.

[Vogel612]

It seems to me this has been superseded by Codename: Cucumber