Re: [AD] Feature-freeze?

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On March 25, 2010, Thomas Fjellstrom wrote:
> On March 25, 2010, Peter Wang wrote:
> > On 2010-03-24, Evert Glebbeek <eglebbk@xxxxxxxxxx> wrote:
> > > On 24 Mar 2010, at 11:53 , Elias Pschernig wrote:
> > > > One feature I think we still need:
> > > >
> > > > - Capabilities querying API. Among others it should report:
> > > >
> > > > ALLEGRO_HAVE_SET_BITMAP_TARGET
> > > >
> > > > If this is not available, al_set_target_bitmap cannot be
> > > > (reasonably) used except for using our software rasterizer for
> > > > drawing to memory bitmaps.
> > > >
> > > > ALLEGRO_HAVE_SET_SEPARATE_ALPHA_BLENDER
> > > >
> > > > If this is not available, al_set_separate_blender cannot be used
> > > > (it will just ignore the alpha values passed in and work like
> > > > al_set_blender otherwise).
> > >
> > > Ok.
> > > Shouldn't be hard to add, right?
> >
> > ALLEGRO_HAVE_ is used for the build system so better rename it to
> > ALLEGRO_CAP_* or something.
> >
> > > > Dario (I think) seems to have hit a stumbling block with enabling
> > > > texture stages or something. It would be really nice to have of
> > > > course, but we could release 5.0 without it.
> > >
> > > I think we can import it without that and worry about it after that.
> > > Ok, so it'a not bug-free. If we let it sit, it'll just bit-rot.
> > > Or we take the position that it should be a separate addon.
> >
> > It's too late for this.  Leave it for 5.2.
> 
> Or earlier, I'm not sure why addons can't be added in minor releases.
> 
> > Peter
> >

And on the subject of releases, should the monthly release schedule be kept 
up for minor releases? And what constitutes a good enough reason to 
increment the major (ie the x in 5.x) version?

Lately in open source, regularly scheduled, 1-6 month releases seem to be 
popular, and really seem to contribute to the health of the project.

Can allegro try a new major version (5.2,5.4, etc) every 6 months regardless 
if theres an actual major change?[1] And a new incremental (5.x.n) every 
month, or every two months?

Constant and regular releases does seem to affect the overall health of 
opensource projects. I think it has to do with perception more than 
anything, the project doesn't seem dead, so people are more willing to give 
it a shot. And not sitting on bugfixes because they don't seem important 
enough at the time to make a full release makes sure people won't get them 
when they need them, seems like a good idea, even if it means a incremental 
release has one or two fixes. Along these lines, maybe the "release manager" 
should alternate each time, so people don't get bored, or burned out. Maybe 
too much for a smaller project, I'm not sure, but I can't see it being a bad 
thing.

* 1. if monthly, or bimonthly releases are made I can see things picking up 
a little, which should mean actual major changes should appear to make a new 
major version increment not pointless.

just my $0.02

-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/