Grzegorz Kossakowski wrote: > Vadim Gritsenko pisze: > >Grzegorz Kossakowski wrote: > >> > >>I wanted to know what are our rules. Do we: > >>- want to have such a internal releases > > > >I'd avoid using word "release" for this as it has some legal > >implications and we would get chewed up for using it :) > > Ah, I'm young committer so forgive me that I omit legal implications and > use inappropriate words. I'm really hard working to improve my English. :-) > I agree it should not be called release.
Many people use the term incorrectly. See http://apache.org/dev/#releases http://apache.org/dev/release.html#what > >Yes I think you can do such builds and place them on your private space > >at people.apache.org or on cocoon zones, and call it "nightly" or > >"build" or some such, but not a "milestone *release*". > > > >And it is a good idea to do such builds as long as it helps to further > >development of Cocoon. > > +1 > > >IMHO, for milestone *release*, I'd bundle all necessary unreleased > >dependencies and upload to www.apache.org/dist. I'm not sure if there > >are any legal gotchas with this approach, but it worked for us in the > >past, for 2.1 milestones. The only stuff that can go at w.a.o/dist/ is that which is intended to be released to the public beyond our "dev" group. Anything put there must be approved by this PMC. > It will not work with Maven and it can't be called "release" I think. My > personal opinion is that release (after changing wording) should be > something that we can officially ship using our infrastructure. Part of our > infrastructure is Maven now but in order to upload to its central server we > can't have snapshot dependencies as pointed out earlier. > The only solution I can think of is that we stay longer in "nighly build" > mode and we can switch to milestone mode as soon as all of our dependencies > are released ones. > I think that it will work well only if we successfully "push" projects we > depend on to follow "release early, release often" practice so we will not > bed forced to stay in "nighly build" phase too long. > > I'm not so much experienced with Open Source to have a strong opinion on > this. Do you think that we effectively "push" other project? The only effective way is to go and help those other projects: testing, feedback, etc. -David
