[tei-council] Options for freezing and/or archiving Lite

[Martin Holmes]

Following our telco today, I was tasked with starting the conversation 
about what we mean by whatever it was we decided to do with Lite at Ann 
Arbor. This has been variously referred to as archiving, retiring, or 
freezing. Here are some of the options as I see them:

1. Full archiving (no more development, no more building, no more 
changes, no more testing):

	Lite would be compiled and released as normal with the next release, so 
it would end up in the Vault for that release. Following that, it would 
be removed from the development trunk, and all links to it would point 
to the Vault version. The Lite ODD file <schemaSpec> would be linked to 
the version of P5 it was compiled with.

	Advantages:
		- Lite would be a fixed, known quantity.
		- We would not have to do anything at all with it from that point.

	Disadvantages:
		- We could not respond to any requests for updates, no matter how 
useful they might be.
		- The Lite ODD file might not continue to "work"; although it would be 
hard-linked to its release version, subsequent changes in the ODD spec, 
the build process, or the ODD processing behaviour could break it, so 
people trying to customize it might have problems.

2. Freezing (no more development, but Lite continues to be built and 
tested as part of the build process, and remains in trunk and in the 
release package):

	Lite would be compiled and released with every release. It's not clear 
whether it would be hard-linked to the P5 version in force at the time 
of the freeze or not; there are advantages and disadvantages each way. 
Bugs emerging out of testing would be fixed, but no other development 
would take place, no matter how apparently attractive the suggestions 
might be.

	Advantages:
		- Not much work for Council.
		- Lite remains functional and people should still be able to create 
their own customizations of it.

	Disadvantages:
		- We appear to be continuing to "maintain" it, so we will be subject 
to pressure to implement feature requests, especially when useful new 
features are added to trunk which people would like to see in Lite.

3. Active maintenance (no active development except where there are 
strong arguments in favour, but Lite is actively built and released as 
normal):

	What happens now would continue to happen, and we would respond to bug 
reports and entertain feature requests, although we would try to resist 
acting on the latter.

	Advantages:
		- Lite users are presumably happy because their customization is 
actively maintained.

	Disadvantages:
		- More work for Council.


Does anyone see other possible scenarios?

Cheers,
Martin
-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)