The proposal looks generally ok to me. I'll try to follow it when working on Toolchains. I'm sure I'll have questions on the way.
more regarding api changes below. On 6/26/07, John Casey <[EMAIL PROTECTED]> wrote:
I like this approach, and I think it's just a slightly more detailed version of what some of us are already trying to do when we put together major new pieces for Maven. I agree with Eric that any API or behavioral change should probably follow this process, basically anything that could change what the user experiences. However, for me, it'd be nice if we could follow this documentation/ratification process with some enforcement and quality controls. For instance, I'd love to see something that would help us improve our test coverage (not just LoC, but functional coverage), and other pieces that would help keep us honest on API modifications. Clirr can do the latter, but I'm not sure there's a good tools for the former, as code-coverage doesn't tell the story of how much of a claimed feature actually works...that's more of an assessment of test quality as well as population.
I'm not clear what is considered API within the codebase and what is the level of commitment for backward compatibility for various parts of the project. to get this in relation to my day job at netbeans.org.. there we have a clear line what is "stable" API that shall remain binary compatible as much as possible. Then there's "friend' APIs that are less strict and a list of known users of the api is kept, limiting the change impact scope. It's known what packages are part of the API, the API Consumer/ API Provider contracts are clearly separated and the APis are created with future extensibilty in mind. Each change to APis is documented of course. however in maven codebase the lines are blurred to me. 1. plugins can basically use almost any component from the core, they can also provide implementations of components. what packages and components compose the official API towards the plugins and which are just internal to the core? 2. each component has an interface and a public default implementation. Are both part of the API contract or just the interface is? 3. what is the actual API we want to keep compatible? with what previous versions? 4. do we have a deprecation procedure? (like keep something for 1-2 releases deprecated and remove it afterwards?) Regards Milos
This is definitely a step in the right direction, and should help us tame the release process a little more. Hmm, we should be writing all of this down for posterity...How We Tamed the Maven Development Process. That way, rather than being hypocrites for talking about idealistic dev processes that we don't follow, we can join the masses in our migration toward that ideal. ;-) Cheers, -john On 6/25/07, Eric Redmond <[EMAIL PROTECTED]> wrote: > > I kind of like the idea of this process applying to any API change - even > if > it's just a bug fix, not necessarily a feature request. > > It would also be nice to either have the "Work" articles under "Work in > Progress" themselves contain contain the related JIRA issues (since there > could be more than one, like ArchetypeNG) - either that or dictate that > each > proposal has one "feature" JIRA issue (that you can link others to). I > don't know if this is already supposed to be the process, but it's clearly > not being strongly adhered to. > > Something minor - I don't know if it was a graffle gaffe (ha) but it might > get confusing having two steps named "Approved Proposal". I would imagine > one moves the draft to "Approved" before working on the project - which is > kind of redundant since once it's approved it moves to work in progress. > > How about "Drafts", "Pending" and "Complete"? > > Thanks; > Eric > > On 6/25/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > > > Hi, > > > > As part of trying to make the whole process of making changes and > > adding new features transparent to everyone involved I've whipped up > > a little sketch for perusal: > > > > http://people.apache.org/~jvanzyl/DevProcess.png > > > > Basically it revolves around making sure things are documented in the > > Wiki and providing a clear record of the evolution of the project > > that anyone can follow at any point in time. So far from perfect but > > I think a good starting point and I would like to field feedback so I > > can improve it. It basically revolves around the dashboard where I've > > tried to collect all relevant information about the project: > > > > http://docs.codehaus.org/display/MAVEN/Home > > > > And process is based around making proposals that eventually will > > serve as the record of evolution of the project. The goal is not to > > have anything that's heavy, and that we might eventually be able to > > automate some data gathering but for the meantime it's not overly > > onerous and provides some visibility we have not yet had to date. > > > > The proposals are all here: > > > > http://docs.codehaus.org/display/MAVEN/All+Proposals > > > > And they basically move from draft -> pending -> approved. I've put > > some notes in the diagram and I figured we could start with a simple > > proposal to see how it works and iron the kinks as we go. This is > > experimental but I see it as the best way forward for getting a clear > > view of what's going on > > > > Thanks, > > > > Jason > > > > ---------------------------------------------------------- > > Jason van Zyl > > Founder and PMC Chair, Apache Maven > > jason at sonatype dot com > > ---------------------------------------------------------- > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Eric Redmond > http://www.sonatype.com > -- John Casey --- Maven Developer (http://maven.apache.org) --- Blog: http://www.ejlife.net/blogs/buildchimp
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
