Hi all, during the last two bigger releases (DBI-1.612 and DBI-1.614) we released the final distribution with some stress, which causes in errors which requires immediate action (DBI-1.612 failed in Win32, DBI-1.614 failes when blanks are in the full qualified path names of the test directories).
This is unsatisfying - and I agree to Tim that the current way of development (everyone commits everytime on the trunk) isn't a suitable way to develop on DBI. I'm a bit confused about the immediate requirement of a fix for RT#61445 and not even a development release 2 days after the fix has been committed, but I think this is just a result from the current confusion. I decided for myself, that I don't commit to the DBI before we have an agreement how to develop and how to communicate about releases. I don't plan to immolate my weekend with the family more often. Background: I'm on the road over the week for a project and see my family only at weekend. So releases at Friday or Saturday can be poison for my weekend. Tim suggest that Pure-Perl DBD development can happen in branches and they should be merged into the trunk when they are ready. Well, I had merged the state of r14409, because I rated it ready, but I hadn't merge a day before a final release. On the other hand, are the git users able to use the svn branches? Is it a suitable way to step further? For releases, I suggest a reasonable person (probably Tim) announces a freeze date (around a week before the freeze starts), from this date on no unreviewed commits to the DBI trunk are allowed. A freeze should take at least one week, longer if required. Further development can happen in branches which are merged back to the trunk after Tim unlocks the branch. If we use branches, we shall agree how to compute the branch names: I suggest: branches/$(origin)-$(reason), e.g. branches/trunk-DBD_DBM_Create_Table_Fixes when branched from trunk or branches/DBI_1_614-Fix_whitespace_in_path_error when branched from a tag. Does it sound as a way we can agree? If those branches aren't a good way, svn supports externals (see http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html). The Pre-Perl DBD's can reside in an own repository and are bundled as released. /Jens
