Hi guys, a new branch has been created where we are supposed to introduce some major modifications and new features. That's fine. However, I would like everyone to be aware of some traps we should not fell in :
1) We currently have a live trunk, which will be used to release a 1.5.2 release sooner or later (a bug fix release). We have to find a way to merge changes from the trunk to the branch _or_ from the branch to the trunk without jeopardize the trunk 2) Even if this new branch is just a branch, at some point we may ask ourselves if this will become the new trunk for a 2.0 (ie, will we abandon the current trunk or not) 3) Our number of committers is big : we are more than 10, and at least 5 of us are directly working on the server. If we start pouring some new features and doing some big modifications, we will have to document what we are doing, and to share the information I would like to be a little bit more precise about point (3) : - we can have big spreaded modifications, like switching from String/byte[] to Value - or we can have local modification (even if they are big : like XmlBeans). the second kind of modification can be done quite easily, but the first kind of modification should also be done in seperate branches, otherwise the server will become a big f*** mess quickly. Also keep in mind that we have a roadmap, so try to stick to it : a modification can be tagged as a JIRA fix (we just have to inject some new JIRA, probably prefixing them with a tag like [bigbang]), making it easier to see the consequences of a modification. The documentation is absolutely necessary, as some of us have a deep knowledge about the server internals, but this is not a general case. If we introduce deep modifications without documentation, then - people who had some knowledge about the server will lose it - and you won't be able to share your vision, leading to some potential bad choices. In three words : share your vision ! Confluence Is The Way, Mailing List Is The Messenger ! I don't want to scare you all, but we must be careful. We are not anymore in the ancient ages of ADS where 2 or 3 persons were working in caves with stones and wood drafting the 1.0 release... Let's try to cut this 2.0 in a way all of our committers can jump into the common work (I'm also thinking about Studio, which will be impacted by this effort, and about our doc writers, which will have to understand what are the new features about without having to crawl into the code). Last, not least, keep in mind we are targetting VSLDAP compliance for this 2.0. Yes, yes, I know, it's not funny... But this is a live project ! Emmanuel -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
