Idea - Split Classic Shell components into seperate repositories

[jdunn0]

Classic Shell currently consists of a few separate components that are developed and released with one installer that can install one or all of them.

The different components however do different things and I think it would be better for development to make each component, a new software project with it's own name, installer, GitHub issues section and separate releases.

I don't really see any reason to keep all the components under one GitHub repository when they do different things.
One component is a Start Menu, one adds a toolbar to File Explorer (The Windows 8+ name for the Windows Explorer File Browser) and one restores the IE6 look to IE7+,

Each component having their own name would also help with the things talked about in issue #13 as each component could have their own, more accurate name instead of just being a component of Classic Shell.

It also benefit the users that only use one component of Classic Shell as it could be installed on it's own.

The "Classic Shell Update" tool wouldn't really work anymore but it could be replaced by a new software project that handles automatic installation of new versions of each the different programs.
The replacement software could be a build of Google's Omaha project which can handle the automatic checking for updates and update installation for multiple software projects.

Omaha is the project behind Google Updater that handles automatic update checks and automatic update installation of all Google software.

Omaha is a little bit complex but when setup, it can work quite well.
Here is how Omaha works:

1. Each program has their individual installers that automatically install Omaha when they are installed if it isn't already installed by another program.
2. The installer registers the program with Omaha via registry entry.
3. Omaha runs in the background at various times via the Task Scheduler function of Windows to check for new updates.
4. If an update is available then the programs new version installer is downloaded and installed slightly in the background when the program is not running.
5. Omaha will be uninstalled when the last program to register with it is uninstalled.

The fork could be called "[New Organization] Updater" where "[New Organization]" is the name of the new organization in GitHub as discussed in issue #13.

All the newly split out components could be repositories under this GitHub Organization too.

[BoatrightTBC]

And, if it's done under an organization instead of personal, then the organization has several repos... Shell, Explorder, I.E. (which needs to be discontinued. Please kill IE now with a big stick.)

So, if the organization is "Open Classics" and it has three repos, which are forks of classic shell...

• Classic Start
• Classic Explore
  *Classic IE -- which is tagged in the readme as deprecated.

Creating an organization is easy, someone just does it, and then assigns more-than-one github account users as organization administrators. Ideally, it makes sense to create an organization email account somewhere that can be passed along as admins come and go. Something as simple as "[email protected]" is sufficient.

Organizations are free, and can have as many free open-source public repositories as they need.

Once it exists, and you've forked Classic Shell into it, we should ask to have a link to the org's main github account page put on the old Classic Start page as a link to the open-source project.

At that point, as people are added to the project, they can be given very fine-grained rights to the various repos.

Beyond that, at present, no other legal organization is required. Eventually, you may want to register the org as a dba somewhere, or as a corporation and ask one of the various open-source project hosting agencies about hosting a project web-page, or you could just create a project web page at source-forge.

But without the basic organization account at github, the entire project is dependent on one developer not getting hit by a bus.

[coddec]

@XenHat @ge0rdi @Quentinix
The ideas from @BoatrightTBC and @jdunn0 is great I guess.

But even to take the first step after separate repos are all set, which is to split the components/parts/code/installer everything can be problematic seems to me. I can be wrong though.

I suppose you guys are busy and have minimum time for maintaining this project.

So..
First things first, we need to give the project or different components names if we want to move on this way. (See #13 for current progress on naming)

1. We might need more people who are experienced and have time for this, since I don't know much about C++ specifically and @XenHat @ge0rdi can be busy time to time, well, they know much more C++ stuff than me ;)

Correct me if I'm wrong.

BTW, @BoatrightTBC The organization was created awhile ago, we did not publish the url due to naming issue, I like your avatar btw ;)

[Ashus]

IMO Classic Explorer's status bar and Classic Start is needed in current Windows. Other parts could be dropped if needed to ease the future development.

[B00ze64]

I think Classic Explorer "Share Icon" and Toolbar are also needed, but I have not yet tried to get rid of the ribbon in Windows 10 (does the toolbar work when the ribbon is active?) I use both features on Win 7 (I have only a token Win 10 partition, I have not yet tried to customize it.)

[coddec]

Future issue submission: https://github.com/passionate-coder/Classic-Start/issues
Any future development will be made at the above address.

[Ibuprophen]

I'm actually surprised that @coddec didn't clone this (and any other applicable ones related to it) repository to sever it from its predecessor by now.

Just a thought/suggestion/recommendation... :-)

~Ibuprophen

[coddec]

@ibuprophen1
Cheers!
https://github.com/passionate-coder/Classic-Start/issues/34