I think we need to evaluate each patch on a case by case basis. With
that said, there certainly are guidelines we probably should follow:
1) new functionality = next release
2) bugfix (simple or low risk fix) = this release
3) bugfix (complex or high risk fix) = next release (unless it is
really important and gets a lot of testing and extensive code review
then possibly this release)
If we are going to start to see a lot of activity for jdbc (something I
am certainly hoping for), we might decide to have a jdbc only release
between 7.2 and 7.3 as the next release. We could create a branch in
CVS for this work if necessary then release the result on the
jdbc.postgresql.org web site. I don't think this work should go into
the 7.2.x branch.
thanks,
--Barry
Bruce Momjian wrote:
>>We have quite a few code changes which I am unsure about at this point.
>>There are quite a few contributions which are coming in right now. I am
>>unclear as to how to handle the 7.2/7.3 thing
>>
>
> It is always a tough decision.
>
>
>>I don't want to lose momentum, but I also don't want to put out buggy
>>code?
>>
>
> Yep, that is the tradeoff. At this point we usually only add bug fixes
> or features that many people really need.
>
>
>>A number of the contributions are implementations of the driver which
>>didn't exist before. Since none of the core code is being modified, I am
>>tending towards adding them as they com in?
>>
>>The contributions that I am aware of include
>>
>>MD5 passwords
>>Exported/Imported keys
>>Fixes to getTables
>>
>
> The decision is up to you guys now. :-)
>
>