Documenting the breaking changes

[Steve Lime]

I'm wondering if an RFC is the right place for long-term policy documents. I suppose they
are our are best choice. I do think we should support the concept of versions then with each
version requiring a vote. I can't see creating new RFCs whenever there is a need to tweak
something.

As an aside, I trimmed the migration document for 4.10-> 5.0 last night, defined a few default
sections and added content related to RFC's 19 and 26. So, that is started...

Steve

>>> Tamas Szekeres <szekerest at GMAIL.COM> 06/06/07 2:47 PM >>>
2007/6/6, Steve Lime <Steve.Lime at dnr.state.mn.us>:
> I think the policy belongs in some sort of a committer guidelines document. RFC 7
> details what we have so far, see http://mapserver.gis.umn.edu/development/rfc/ms-rfc-7.
>
> That document should be revised to refer to recent moves to trac and svn, with references
> to TSC changed to PSC. Might also add a section on licensing- don't commit code you are
> not authorized to, code takes on the MapServer License, and so on.
>
> Any reason why an RFC like that couldn't undergo periodic update?
>

Steve,

I don't think if we have such an agreement that an RFC cannot be
superseded by a new one. But surely every new version would require a
new voting sequence for the approval.

I'm fairly supportive with the changes described above.

Best regards,

Tamas