FDRepo v3 Development TODO

Stage 1:

	This stage is enormous. It basically is everything required to manage multiple FreeDOS
	software download and update repositories on the server which are compatible with DOS
	command line utilities like FDNPKG. This includes all the underpinning technology to
	manage that repository. Including things like repository layout migration, repository
	"healing", package management and a bunch of other features.

	Completed.

Stage 2:

	Fairly large stage. This will be the development of the browsable static HTML pages.

	Completed.

Stage 3:

	Final stage needed to fulfill the absolute minimum required to replace FDRepo v2.
	It is all the user/vistor facing stuff which was provided in v2. This includes the
	Optionals. ISO image creation. RSS feed generation. Package comparison charts. Etc.
	Support for screen shots will be completely new and is not part of this stage.

	Completed.

Stage 4:

	More server side stuff. Command line options to add, edit, remove
	and move packages. Support to add packages from a path on update.

	Completed.

Stage 5:

	Officially release FDRepo. Deploy it to the official repository replacing v2.

Other things left for later (may or may not happen)...

	- change default shown order of package metadata

	- do not show summary if it is the same as the description.

	- maybe exclude showing "modified-date" or "Entered-date" when on the same day.

	- Link to Groups, packages versions in the comparisons table.

	- Maybe add XML sitemap generator.

	- Create HTML FileList pages.

	- Maybe add Prev/Next Buttons to Package View.

	- GitLab and Collaboration support. The ability use the command line interface to
	fetch package updates directly from a branch in the FreeDOS GitLab Archive and store
	them locally. Optionally, to perform this task at intervals and automatically add
	them to a repository. Also, similar abilities with regards to specified repositories
	that are provided by FDRepo on other websites.

	- If a package is manually placed into a different package's versioned directory, it
	will be	versioned as if it belongs there. Instead, healing should check if that
	package exists somewhere else in the repository and relocate it. If it does not exist
	somewhere else,	move it up to the group level instead.

	- A package is identified by it's DOS file name. It can only exist in one group.
	Healing should scan the repository for conflicting packages names in the groups
	and provide an error message.

	- Set meta tag links and image URLs in the Available Repositories Index HTML files
	to the "default" repository. At present, they just point to whichever repository
	was active when they were created during a "heal".

	- Add support for Nested Macros like: <!@url:<!@language>.csv>

	- Add wild card support to package id for things like info, versions, edit, delete.

	- Add support for additional template sections. Like Top (between navbar & content)
	and Bottom (between content & language). Plus page specific ones to go between
	Top & Content (PageType_Above) and Content & Bottom (PageType_Below)

	- Add ability to automatically fix entered-date in LSM metadata.

	- Support for separate Binary and Source packages.

	- Repository forking.

	- Possibly reduced disk usage through a common package pool.

	- Support a Repository of only LSMs files that point to external sites.

	- DOS Text based Web 0.1 HTML pages. (probably not needed since Lynx works very well)

	- maybe convert LSM metadata to UTF-8 and LF before passing to external editor.

	- When pulling packages from "upstream" and an error (or CTRL+C) occurs after
	  a project is cloned, but before the zip file is created and stored in the
	  upstream storage area, the project will not be checked again until it has
	  been modified once more upstream. This can be improved a little to permit
	  trying again if it was CTRL+C and not a error.

	- Option for package created from upstream changes to include all changes since
	  last creation instead of lastest package in repository.

	- command-line option to delete screenshots

	- command-line option export screenshots

	- command-line option to add screenshot to only one version of a package. (already
	supported by package version pages.)

	- delete screenshots when package is deleted

	- Maybe base version specific snapshots on Version not Modified-date.

	- Performance enhancements and some other stuff. :-)

