On Wed, Jan 12, 2011 at 1:09 PM, Sandro Tosi <mo...@debian.org> wrote:
> On Wed, Jan 12, 2011 at 18:20, Benjamin Root <ben.r...@ou.edu> wrote:
> > I am fine with letting 1.0.1 go out as is (unless we can't live with the
>
> is already out: look at SF download page to see how many have downloaded
> it.
>
> > documentation typos that has shown up). I am also hesistant about
> putting
> > out yet another bug-fix release because there will be distros that will
> have
> > 1.0.0, 1.0.1, and then possibly others with 1.0.2, which would turn into
> a
> > maintenance nightmare. Instead, let's just let those package maintainers
> > keep up with the patches to 1.0.1.
> >
> > This also raises a question. When putting out maintenance patches, are
> we
> > going to have to patch 1.0.0 and 1.0.1?
>
> If you're saying you want to publish another tarball with version
> 1.0.1 that has different contents of the current one, than with my
> distro package maintainer and programmer hats on I say "you should
> not". If you have published (and not advertised, ok) something, you
> cannot re-publish the same version but with something "different" in
> it. Just go with 1.0.2, distros have (usually) the latest version and
> you are free to release patches in the HEAD of your development tree:
> it's a distro package maintainer evaluate if this patches are to be
> backported to the distro version, if the version cannot be bring
> up-to-date with the latest release.
>
> Cheers,
>
I believe we are actually in agreement, but perhaps I wasn't clear enough.
The maintenance patches that I speak of are committed in the v1_0_maint
branch of the svn repo. The tarball still has the original code from the
release point regardless of what patches have been committed since then.
Package maintainers can choose to cherry-pick those patches or even track
that maintenance branch for their own packaging purposes. The point is that
new features should not be added (unless absolutely necessary) and that old
features are not removed on that branch.
Please see our coding guide under "Committing Changes" (particularly the
last bullet):
> Keep the maintenance branch (0.91) the latest release branch (eg 0.98.4)
> and trunk in sync where it makes sense. If there is a bug on both that needs
> fixing, use svnmerge.py <http://www.orcaware.com/svn/wiki/Svnmerge.py> to
> keep them in sync.
>
So, back to the issue regarding whether to put out a 1.0.2 or not. We will
always be wanting to patch things (lord knows there are enough bugs...) and
at some point we have to say "it is good enough". Right now, my only major
qualm with the current 1.0.1 release has been the documentation (by the way,
the Coding Guide page looks terrible on my small screen). Code-wise, I am
willing to accept it as is and start focusing on 1.1.0.
Ben Root
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
