For Programmers: Free Programming Magazines  


Home > Archive > PHP PEAR Questions and Answers > January 2005 > Re[2]: [PEAR-QA] Re: [pear-webmaster] Re: [PEAR-QA] Thought about unmaintained packag









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Re[2]: [PEAR-QA] Re: [pear-webmaster] Re: [PEAR-QA] Thought about unmaintained packag
Anatoly Techtonik

2005-01-19, 4:19 pm

Hello Klaus,
[color=darkred]

KG> Not quite... because the idea is to add two columns: one for the name of
KG> the package that supercedes it and the other for the date/time of the
KG> depreciation. Since the name of the package would be a tinytext field (I
KG> suppose), it wouldn't do any harm to simply put "unmaintained" in there.

I can offer adding
status enum ('OK','ACTIVE','INQUIRY','UNMAINTAINED',
'DEPRECATED')
status_change DATETIME
status_related VARCHAR
'OK' -> NULL
'ACTIVE' -> link to current activity info
'INQUIRY' -> link to QA tracker? (doubt there will be any)
'UNMAINTAINED' -> NULL (but in presentation layer button to apply)
'DEPRECATED' -> name of successor

To tell the truth I prefer this status to be in separate table, so
events could be added to it and sorted by date like:

package_id
status_date
status
status_related

(package_id status_date) - PRIMARY KEYS

GROUP BY package_id ORDER BY `status_date` DESC

Additional maintenance DB queries:
check names for deprecated packages

These modification can take 20 minutes to do or many days to talk.
I think the problem is not in implementation, but in people who
can do this practically.

KG> On the other hand, what you say below is true. In fact, I'd almost
KG> suggest linking based on package ID rather than package name (if it
KG> depends on user input, it could make a mess if someone enters a package
KG> that is not in the DB). I'd suggest a selection box something like for
KG> maintainers... but n to 1 selection... But maybe that's overkill. At any
KG> rate, even if "unmaintained" in the field signifies unmaintained status,
KG> it probably would be best to put that in the interface as a checkbox.

KG> Come to think of it, a package may be maintained but depreciated... And
KG> another unmaintained but not depreciated. So I guess the best way to
KG> solve the problem is to simply add a field indicating whether a package
KG> is maintained or not.

Please provide an example where package is maintained or deprecated?
To me 'Deprecated' implies 'Unmaintained'. If you have time to report
bugs and use deprecated package - you can always follow old PEAR
tradition and contact former developers. It is Ok if you will not
recieve support either it is deprecated package or unmaintained.


t
--
Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com