Hi Patrick,
Is every commit on master considered stable? How are releases validated
currently?
We use a git-flow style release strategy currently for our projects and
would need to follow the same strategy here for QA reasons (there's many
great blog articles on the benefits of doing this if you want to know
more).
The implication for our interaction with this project is that we would fork
master at some point and begin applying patches to stabilize it as issues
are discovered. This patch queue would be contributed back to master but we
would not want new (possibly buggy) patches merged with our stable branch.
We would not release off of master again until until enough useful features
had accumulated to begin going through another stabilization spiral. We do
not plan on developing new features and would really like to focus on
stabilizing (as necessary) and using the library.
We will also probably create some minor tooling so that our development
team can leverage the libraries through Java without having to build the
project themselves, and would be interested in pushing this as a versioned
artifact into Maven central.
We can (and will) do all this under our own namespace so there's no
confusion, but if the community would like to collaborate we think that
would be best.
On Thu, Jul 31, 2014 at 10:10 AM, Patrick Fuller <patrickful...@gmail.com>
wrote:
> Why not just use the git commit uuids? Something like:
>
> git clone openbabel/openbabel
> git checkout 92ab8c8
> cmake, make, make install
>
> should ensure that everyone is on the same exact version of the code.
>
>
> On Thu, Jul 31, 2014 at 9:05 AM, Ed Kohlwey <ekohl...@gmail.com> wrote:
>
>> Hi,
>> I'm working on a project that would like to make use of some features in
>> the master branch.
>>
>> I'm contemplating three options and would like to know what the developer
>> community thinks:
>>
>> 1. Backport needed patches off of master to the 2.3.2 release branch and
>> begin maintaining our own release with additional patches, probably labeled
>> 2.3.2+xyz
>> 2. Help the community create a 2.3.3 or 2.4.0 release off of master
>> (whatever is needed to do that)
>> 3. Create our own release off of master and start a numbering scheme that
>> is unambiguously not the same as the current OB scheme.
>>
>> We have no intention of forking the code but do need to have versioned
>> releases for QA purposes.
>>
>> Please let me know what you think!
>>
>>
>> ------------------------------------------------------------------------------
>> Infragistics Professional
>> Build stunning WinForms apps today!
>> Reboot your WinForms applications with our WinForms controls.
>> Build a bridge from your legacy apps to the future.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
>> _______________________________________________
>> OpenBabel-Devel mailing list
>> OpenBabel-Devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>>
>>
>
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel
