Comments below; we should also add the LICENSE and NOTICE files to
each of the JARs since this has become best practice for Apache
projects.

Eddie


On 11/2/06, Carlin Rogers <[EMAIL PROTECTED]> wrote:

- doap_Beehive.rdf -   I have not yet modified the DOAP. Do we just

[eko] Once the release is done, we'll need to add a new <version>
block to the <release> section to the doap file in trunk/.  You can
ignore the one that was branched because the one in trunk/ is used to
generate http://projects.apache.org.

- docs/maven-support.txt -   is this just a readme text file and
should I update the versions at the bottom of the doc?

[eko] It's just a readme -- no need to update it.


- POMs -     looks like these use a property for the beehive version, correct?


[eko] Correct -- the @beehive.version@ string is substituted when the
build runs and is just changed in trunk/beehive-imports.xml

I haven't made any changes in beehive/site/... yet. I guess we wait
until the release to update these.

[eko] Right -- once we've voted on a release, the site changes to add
links to the new 1.0.2 documentation bundle and to add a link to the
download page.


I'll start the work to remove incomplete data grid features in branch.

Thanks for your help.
Carlin

On 10/24/06, Carlin Rogers <[EMAIL PROTECTED]> wrote:
> Excellent and thanks Eddie. After Wednesday sounds fine. I'm also
> happy to help if that makes it easier for you.
>
> Your idea of including the LICENSE file in all the jars sounds good as well.
>
> Kind regards,
> Carlin
>
> On 10/23/06, Eddie O'Neil <[EMAIL PROTECTED]> wrote:
> >   Sure -- that'd definitely help.  As my slow replies probably
> > indicate, I've been busy with some other things and haven't been
> > super-active recently.
> >
> >   There are several tasks that need to happen for release:
> >
> > - branching
> > - remove incomplete data grid features in branch
> > - update version numbers in the documentation, build, and POMs
> > - create / sign release package
> > - vote on release package
> > - publish approved binaries / maven distributables / refreshed documentation
> >
> >   I'll be able to help with branching / data grid work after Wednesday
> > and can take care of the release packaging / signing after that.  If
> > you'd like to get started before then, take it away.  :)
> >
> >   One thing we should review is whether we need to include LICENSE
> > files in all of our JARs.  My reading of this:
> >
> >   http://www.apache.org/dev/apply-license.html
> >
> > indicates that we don't strictly need to do this -- but other projects
> > are currently doing this so that the JARs are self-describing outside
> > the context of the distribution package.  I'd be in favor of doing
> > this work.
> >
> > Eddie
> >
> > On 10/16/06, Carlin Rogers <[EMAIL PROTECTED]> wrote:
> > > Hey Eddie,
> > >
> > > I could volunteer by creating the branch and backing out the changes,
> > > if that would help.
> > >
> > > Are there other release tasks that you think some of us other folks in
> > > the dev community should/could be doing?
> > >
> > > Kind regards,
> > > Carlin
> > >
> > > On 10/16/06, Eddie O'Neil <[EMAIL PROTECTED]> wrote:
> > > >   #1 wouldn't be a lot of work and is basically just a couple of
> > > > changes to revert.  AFAICT, that's my task unless someone else wants
> > > > to volunteer.  :)
> > > >
> > > >   The problem with shipping an incomplete feature is exposing
> > > > unfinished and unfrozen APIs.  This means that the APIs could change
> > > > in the future potentially breaking applications that used such
> > > > features, and this doesn't seem desirable.
> > > >
> > > >   Plus, I tend to believe that patch releases should be as stable as
> > > > possible to ensure continuity from a previously released version.
> > > >
> > > >   My $0.02.
> > > >
> > > > Eddie
> > > >
> > > >
> > > >
> > > > On 10/16/06, Scott Musser <[EMAIL PROTECTED]> wrote:
> > > > > How much work would there be in option #1?
> > > > > Naturally it would be cleaner than option #2 but I agree with Carlin 
that
> > > > > either option would work.
> > > > > Finishing the partial data set support could then be finished when 
you have
> > > > > time rather than rushing.
> > > > > Would the impact of shipping incomplete data set support be 
disagreeable to
> > > > > the rest of the community?
> > > > > It would be useful to understand what will the ramifications of 
shipping
> > > > > this incomplete feature might be.
> > > > >
> > > > >
> > > > > On 10/13/06, Carlin Rogers <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Hey Eddie,
> > > > > >
> > > > > > Are you thinking there would be some API changes in what you have 
for
> > > > > > the datagrid partial data set support to make it fully baked or just
> > > > > > some clean up? I'm not a binding vote but I'd be good with either 1 
or
> > > > > > 2 (if there's nothing drastic in API changes for data set support).
> > > > > >
> > > > > > Carlin
> > > > > >
> > > > > > On 10/13/06, Eddie O'Neil <[EMAIL PROTECTED]> wrote:
> > > > > > >   Hm -- a new release would be great except...
> > > > > > >
> > > > > > >   I've started new feature work in trunk/ for supporting partial 
data
> > > > > > > sets; this work isn't baked / frozen yet.  Some options:
> > > > > > >
> > > > > > > #1) branch, remove the partial data set support, and ship 1.0.2
> > > > > > > #2) ship partial data set support as-is in 1.0.2
> > > > > > > #3) finish partial data set support and then ship 1.0.2
> > > > > > >
> > > > > > >   Thoughts?
> > > > > > >
> > > > > > > Eddie
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 10/5/06, Ken Tam <[EMAIL PROTECTED]> wrote:
> > > > > > > > +1 for a 1.0.2 patch release
> > > > > > > >
> > > > > > > > On 10/2/06, Rich Feit <[EMAIL PROTECTED]> wrote:
> > > > > > > > > Agreed -- seems like 1.0.2 to me...
> > > > > > > > > Rich
> > > > > > > > >
> > > > > > > > > Chad Schoettger wrote:
> > > > > > > > > > It seems like a patch release to me.  We've fixed a lot of 
bugs --
> > > > > > I
> > > > > > > > > > know that in the controls area there have been a number of 
bugs
> > > > > > fixed
> > > > > > > > > > which were found by users using Beehive from within an IDE 
(many
> > > > > > of
> > > > > > > > > > them APT related).  Also bugs releated to security and 
deadlocks
> > > > > > have
> > > > > > > > > > been addressed as well.
> > > > > > > > > >
> > > > > > > > > > I think it would be a good thing to get these fixes into a 
patch
> > > > > > > > > > release at this time.
> > > > > > > > > >
> > > > > > > > > >  - Chad
> > > > > > > > > >
> > > > > > > > > > On 9/28/06, Carlin Rogers <[EMAIL PROTECTED]> wrote:
> > > > > > > > > >> I was wondering about the scheduling of the next beehive 
release.
> > > > > > > > > >> There's been more than 65 bugs and improvements fixed 
along with
> > > > > > a few
> > > > > > > > > >> smaller new features. Some of these seem like good 
improvements
> > > > > > on
> > > > > > > > > >> 1.0.1 and worth getting out to the user community. This 
includes
> > > > > > > > > >> things like a security fix and some page flow deadlock 
fixes as
> > > > > > well.
> > > > > > > > > >>
> > > > > > > > > >> What are the thoughts on whether this would be a patch 
release (
> > > > > > 1.0.2)
> > > > > > > > > >> or a point release (1.1)? Just curious what folks where 
thinking
> > > > > > and
> > > > > > > > > >> getting a discussion started.
> > > > > > > > > >>
> > > > > > > > > >> Kind regards,
> > > > > > > > > >> Carlin
> > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>

Reply via email to