Hi Jeremy,
Jeremy, I was thinking about this branch yesterday and I think you
should branch whole 2.1 and commit your work to your branch.
With your help, I'd be happy to do this.
I've created a branch called "BRANCH_2_1_X-dojo1_1" based on latest version of 2.1 branch. It's your
sandbox now and you can safely play around there without any risk of buildings someone's work or
block any releases.
The URL for branch is:
http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X-dojo1_1/
Lets do it !!
I am getting really close to having all widgets re-written to Dojo 1.1.1
APIs, still not quite there yet.
But as it looks like I have some work coming up that will delay me
further, this could be a good time to get it out.
Actually, now it's very easy, just switch your checkout of Cocoon's source code to the branch and
commit your stuff there.
Don't know which client for svn you are using, but from cmd line it would be:
svn switch
https://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X-dojo1_1/
(https is important here, of course)
I only have one ask to you:
Could you try to commit as small changesets as possible (of course, not to small)? The best
situation would be if one commit reflects one logical change (like migration of one widget to new
API or something like that). Rule would be that one commit is big enough to not introduce
intermediate states where state of branch is completely broken. So half-baked commits are bad idea.
On the other hand, single commit should not contain anything more than is necessary to fulfill
requirement outlined above.
I ask you to split your work into smaller chunks because then it's easier to merge things in the
future and it's much easier to follow your work and port it to trunk. However, I'm aware that when
one is doing heavy refactorings following this rules is not always possible.
Last thing: descriptive commit messages. Even if that may sound obvious, but they are really, really
needed. ;-)
This is especially a case when someone else must keep trunk in sync with your
work.
Apart from my dwindling list or re-writes, there will obviously be a big
list of niggles and bugs to fix, specially as none of this is tested on
MSIE.
Here I hope that we can count on help of our community.
Cleaning up samples
Devising a good scheme for packaging code and i18n
Waiting for a slew of bug fixes that will come in Dojo 1.2
Implementing client-side validation based on cforms validators, not just
datatypes (as I have now)
Is the last item absolutely necessary for initial release?
etc. etc.
There is still a lot to do, but once these last few widgets are written
and all legacy samples work again, people will be able to run and use
it, criticise, tweak, fix, meaning the slope should be downhill :)
:)
Robin, back to your question: I hope that once Jeremy publishes his
work we can all join our forces to push things forward. When it comes
to me, I can help with porting Jeremy's work from 2.1 to trunk.
That would be great!!
Even there is one caveat: for me September is going to be more or less free month and I plan to not
touch computer too much so I could start with porting stuff to trunk in October.
Now, looking forward to your commits!
--
Best regards,
Grzegorz Kossakowski
