Thanks for the great summary Josh!
On Tue, Oct 11, 2011 at 3:45 PM, Josh Moore <josh.mo...@gmx.de> wrote:
> All,
>
> there's been some back-and-forth on the developers' list[1] regarding what
> the next few PyTables versions should look like.
>
> A bug fix (2.3.1) will be released in the next week or so to correct a
> minor build issue which crept into 2.3.0. (As always, our apologies!) After
> that, 2.3 will remain largely bug-fixes-only since it's largely just the
> continuation of PyTables 2.2 with the addition of the caching/indexing code.
>
> Then, there are are two groups of changes which are on the horizon. The
> first group are largish fixes of issues raised perhaps some time ago which
> do *not* require upgrading your Python version[2]. The other group are those
> changes to add Python3 support to PyTables[3].
>
> For the moment, we'll keep changes of each of these types separate (see
> technical details below) so that if there's enough interest in a PyTables
> 2.4 and we can't support Python3 without dropping Python 2.4 & 2.5 support,
> then we'll push out a PyTables 2.4. Otherwise, everything will be rolled
> together in one large super PyTables 3.
>
> Feedback (to the mailing list or privately) on which projects / individuals
> may still need or want Python 2.4 and 2.5 support is *very* welcome. Also,
> if there's anything else you want to see take priority, speak up; again
> here, via private email, or add an issue to github[4].
>
> (Technical details follow)
>
> In order to keep track of the various branches of work, we're planning on
> organizing the git repository[5] based on the git-flow[6] scheme. The
> "master" branch will be considered stable and will have all released
> versions merged into it, starting with v.2.3.0. The "develop" branch will
> contain the ongoing more or less stable work. This would include the first
> group of fixes from above, which would become PyTables 2.4 if it
> materializes. Then there will be one or more branches (e.g. "feature/py3k")
> with more breaking changes which will be merged in when it becomes time to
> release PyTables 3.0. If you are interested in more of these technical
> details, please add yourself to the pytables-dev mailing list[7]. We'll try
> to keep the distractions on pytables-users to a minimum.
>
> Many thanks!
> ~Josh Moore
>
> [1]: https://groups.google.com/group/pytables-dev/msg/2e0003aba7ca364c
> [2]: https://github.com/PyTables/PyTables/issues?milestone=3&state=open
> [3]: https://github.com/PyTables/PyTables/issues?milestone=4&state=open
> [4]: https://github.com/PyTables/PyTables/issues
> [5]: https://github.com/PyTables/PyTables
> [6]: https://github.com/nvie/gitflow
> [7]: https://groups.google.com/group/pytables-dev
>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Pytables-users mailing list
> Pytables-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/pytables-users
>
>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Pytables-users mailing list
Pytables-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pytables-users
