On 24 Sep 07, at 11:21 AM 24 Sep 07, Ralph Goers wrote:
Jason van Zyl said:
On 24 Sep 07, at 9:23 AM 24 Sep 07, Mark Hobson wrote:
Okay, but I do think a feature branch is the best for prototyping
new
features - it stops blocking the developer and doesn't cause
unnecessary problems for others. Do we really need to merge it into
2.0.x? 2.0.8 is due out soon which means users can start using this
prototype which will lock us into supporting this functionality in
future.
I don't think Ralph was planning on trying to merge this as there are
changes in the separated maven-artifact. I don't think this can go in
2.0.8. Ralph, just verifying but you're not intending to put this in
2.0.8 are you?
If there were no objections then ideally yes as the folks I did
this for
really only want to use a formal release of Maven. That is why I
posed
the question first last week. Since I only got feedback from Jason I
(probably incorrectly) assumed no one else objected.
I think people assumed trunk as your original message mentioned
nothing about 2.0.8.
To be honest, this is one aspect of the Maven community that I've been
unclear on since participating here. I've seen folks do stuff in
whiteboards and branches but it has never been clear to me when
that is
appropriate vs. discussing it on the list and committing.
Trying to capture all proposals here:
http://docs.codehaus.org/display/MAVEN/All+Proposals
As things tend to get lost on the mailing lists. You can bring it up
on the mailing list but if it's your proposal then you keep track and
update the proposal for posterity.
For example, I
tried to go back in the dev list and search for where the decision
to drop
properties from individual dependencies was made in Maven 2 and I just
couldn't find it. Maybe my search wasn't specific enough.
No, it's because we didn't have a process of tracking anything
fundamental changes in a little proposals section. It's probably a
tiny snippet in an email, or happened early on in m2 development
where myself, John, and Brett did most things in IRC. It surfaced on
the list but the decisions had already been made at that point. The
proposals section tries to capture anything that happens in mail,
IRC, at conferences or a chat with a friend at a coffee shop. I don't
particular care where the ideas come from provided they make their
way into that proposals section and there is some buy in.
I have been doing refactorings on the trunk, which I probably should
have done in branches too, but I've kept any changes that I would
like to see in branches until there is buy in from a proposal.
If you would prefer this to be on a branch so others can try it I'd be
happy to do that but I doubt we will be able to use it until it is
in a
release. If that is what you prefer then I can revert this tonight.
I'm not really concerned with what your company needs in the short
term. I have _lots_ of things that my clients need in the short term
and I'm using vendor branches. If you make a proposal, nobody minds,
you guarantee if won't interfere and you're going to support the
feature if/when something goes wrong I'm not particular fussed if
you're going to do the work but this is fundamental change to how the
dependencies work and you need some buy in and scrutiny before you do
it because it means you have to support it going forward.
What you need at your company should not be the sole driver for
features. Just like what my clients need shouldn't be a sole driver.
I'm doing all my stuff on branches. Even though I would like to push
things into trunk I haven't and I have at least a dozen little
features here and there implemented. 2.1 just really needs to be
cleaned up first before anyone can understand future changes.
At the very least you should write a short proposal and put it in the
wiki.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
