Delaying 1.0 beta
Jacob Kaplan-Moss
It seems to me that we're not quite ready to get out a 1.0 beta this
week. At least three big features -- signal refactoring, file storage,
and GeoDjango -- are ready for merge, and although we could do those
merges all at once and still do a release, we *always* have a bug-fix
period after any big merge.
So, I think it's time to officially tweak the schedule. In a nutshell,
I'd like to collapse "beta 1" and "beta 2" into a single release next
week. More fully, here's what I"m thinking:
* Don't release anything this week[*]
* Get these features merged *before* the Lawrence sprint this weekend
so we can start focusing on bug fixes there.
* Feature-freeze as planned after this Friday's sprint.
* Release Django 1.0 beta around 8/12.
* Keep the rc1 and 1.0 final release dates the same.
How's this sound to everyone?
Jacob
[*] Another option would be to release an "alpha 2" shortly after
merging these big features. I don't feel strongly either way.
James Bennett
<jacob.ka...@gmail.com> wrote:
> [*] Another option would be to release an "alpha 2" shortly after
> merging these big features. I don't feel strongly either way.
This works for me. I'd rather have an alpha and go to beta from there.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
Marty Alchin
to merge, though, since I'm now working with one of the storage
backend authors to finalize some of the helpers we may provide for
those. The APIs set, but it may still take a day or two to sort out
what we can provide as a base for custom implementations.
I'm *not* considering that a blocker for merging file storage, but if
the three will be merged at separate times, I'll gladly be at the end
of the list. Besides, it'd be better to incorporate the signal changes
into the file storage patch anyway, rather than the other way around.
-Gul
Jacob Kaplan-Moss
1. No release today; merge in the big stuff, though.
2. Tomorrow we release alpha 2 instead of beta 1, so we get people
looking at the new stuff to find bugs.
3. The sprint this weekend does shakedown, stabilization and bugfixes.
4. Next week we do beta 1.
5. Django 1.0 still happens as scheduled.
If anyone's got a problem with this, please do speak up. We're going
to move forward with this slightly-revised plan, but if there's
something we're missing, tell us.
Jacob
Russell Keith-Magee
No problem with this schedule.
One missing item - Comments. If we're collapsing Beta 1 and Beta 2, we
need to get the GSOC code merged in ASAP.
I'd also like someone else to weigh in on #5461. The database backends
are certainly stable and I don't have any particular problem releasing
them as-is, but it would be nice to have a consistent backend API, and
#5461 is mostly about getting just that.
If we choose to ignore #5461, there are a few pieces of cleanup in the
backends that we should do - like deleting the empty BackendCreation
stub.
Russ %-)
Leo Soto M.
<freakb...@gmail.com> wrote:
>
> I'd also like someone else to weigh in on #5461. The database backends
> are certainly stable and I don't have any particular problem releasing
> them as-is, but it would be nice to have a consistent backend API, and
> #5461 is mostly about getting just that.
>
> If we choose to ignore #5461, there are a few pieces of cleanup in the
> backends that we should do - like deleting the empty BackendCreation
> stub.
+1 -- as in it would be cool to know if #5461 is or isn't going to be
included on 1.0!
On the django-jython code [1] I've been assuming that it will, as it
avoids a lot of code duplication on backends that talks to the same
database engine, like PostgreSQL via psycopg, psycopg2 and JDBC. But
if it is not going to land on time, I can revert the particular
changes (i.e, reintroduce the duplication) and live with it.
[1] http://code.google.com/p/django-jython/
--
Leo Soto M.
http://blog.leosoto.com