After putting all oop changes under one commit I think it's now needed to write all decisions in the middle somewhere, so a CHANGELOG could help.

So before starting, I'm going to wait at least one opinion :-)

Comments

sdboyer’s picture

sdboyer commented

CHANGELOG.txt for drupal modules is almost always a bulleted list; whatever we put in there should follow that standard. If you think we need a bigger explanatory text document, that's fine, but it should be a separate .txt document that's referenced in README.txt indicating what's contained in there.

marvil07’s picture

marvil07 commented

I also think that following the standard for the changelog is a good idea, so I'll try to convert all in a bulleted list. And I suppose that if we need more, we can use module documentation here in d.o

marvil07’s picture

marvil07 commented
Version: 6.x-1.0-rc2 » 6.x-2.x-dev
marvil07’s picture

marvil07 commented

handy links to remember(apart from git logs)

WU1: http://groups.drupal.org/node/22839
WU2: http://groups.drupal.org/node/23015
WU4: http://groups.drupal.org/node/23458
WU6: http://groups.drupal.org/node/23905
WU7: fixing all around http://groups.drupal.org/node/24167
WU9: rethinking interfaces, oop-dbtng and autoload http://groups.drupal.org/node/24733
WU12: more interfaces, repo urls, documentation, fixes, loaders, rebasing http://groups.drupal.org/node/25429

marvil07’s picture

marvil07 commented

where to write about the ideas: API changes from 6.x-1.x to 6.x-2.x

marvil07’s picture

marvil07 commented

So, after re-reading the git logs, I decided to avoid pain work on CHANGELOG, and instead work on the handbook page mentioned in #5.

I just edited it, and have a _start_ there, but hoping to make a full list of functions/methods mapping , and for that I think I'm going to take some backend and update it, so I can write useful docs :-p .. any recommendation? (I think svn or cvs backend, which have 6.x-1.x version of api)

marvil07’s picture

marvil07 commented

after talking with sdboyer at IRC, use CVS backend for this task, mainly because we think it implement almost all API, so we can really make sure all stuff is complete.

sdboyer’s picture

sdboyer commented
Status: Active » Fixed

I'm actually going to start up a CHANGELOG, as it's a habit I've recently gotten into. I'm just going to summarize all the work up until now with a single line, keep it simple :)

marvil07’s picture

marvil07 commented
Status: Fixed » Active

Ok

But I want to finish the documentation for API changes from 6.x-1.x to 6.x-2.x, so I will follow writing there and keep this issue open until I end up that, but if you want I can open another issue(IMHO this issue is the right one to track that)

sdboyer’s picture

sdboyer commented

The CHANGELOG isn't really the place to document those anyway - API.txt, Advanced Help, or in d.o book pages, as you're doing. Changelog is more about one-line summary-type changes, if at all, and I'm arguing that we don't really need to document those extensively in the CHANGELOG. So, given that this issue is about the CHANGELOG, let's either change the title of it to something like "Document API changes in 6.x-2.x", or let's close it. I'll leave that up to you :)

marvil07’s picture

marvil07 commented
Title: changelog from 6.x-1.x -- 6.x-2.x » Document API changes from 6.x-1.x to 6.x-2.x
Issue tags: -changelog

btw this kind-of-obsessive-desire to document changes have one main target: review API while porting to cvs backend to the new one

marvil07’s picture

marvil07 commented
Priority: Critical » Normal
Status: Active » Postponed

Since the api on HEAD is changing, I think this will be not relevant for a while

sdboyer’s picture

sdboyer commented

IMO, screw documenting changes from 1.x to 2.x We should just be focused on documenting 2.x.

marvil07’s picture

marvil07 commented
Status: Postponed » Closed (won't fix)

right!