On Fri, Oct 30, 2015 at 9:46 AM, Kirk, Benjamin (JSC-EG311) < benjamin.k...@nasa.gov> wrote:
> > On Oct 29, 2015, at 5:31 PM, John Peterson <jwpeter...@gmail.com> wrote: > > The strip_dup_libs.pl fix has been merged, and I also started an 0.9.5 > branch with stuff for the next release. > > For some historical perspective, I also dug some of the older release > dates out of the SVN archive and compiled them here: > https://github.com/libMesh/libmesh/wiki/libMesh-release-history > > > Thanks guys! As for me, yep - Allison was born Sunday evening and is > doing great. Petite little 6.5 pounder. > Great news! Congrats to the Kirk family! > AFAIK the only distinction Id make between 0.9.5 and 1.0.0 is whether or > not default comm world is enabled for legacy compatibility. In fact - in > the spirit of new beginnings, I'd be in favor of dropping both with > essentially the only difference being the default configure value for that > parameter. > Cool. > Thoughts? > Only other possible food for thought from me is, modulo comments below about versioning scheme, there's a few of things coming down the pipe from my group that may possibly influence thinking here (but doesn't necessarily have to, just FYI). 1. Tim, one my Ph.D. students, is using his HPC 1 project to experiment with object design to replace the current std::vector<std::vector<> > for shape functions in order to allow the possibility of vectorization for fe assembly. I expect him to report results to the list by the beginning of Dec. for discussion (if not earlier). 2. I need to add a feature to NewmarkSolver to enable using the acceleration from the restart (instead of recomputing it). This should happen within the next week. 3. Chris is working on a PR to make assignment of interior_parents part of prepare_for_use (and therefore automatic). We have outlined the algorithm, but there may be unforeseen hiccups (as usual). My only additional thoughts to this would be to try and standardize the version numbering after moving to 1.0.0. I kind of feel like there's not much rhyme or reason to it at present, but maybe I'm wrong. I'm not particularly attached to any one scheme (although I do like major version change breaks backward compatibility, minor version is new features, and micro is bug fixes only), but just so we can point to some policy so people have a better idea. Just my two cents, not trying to raise a stink.
------------------------------------------------------------------------------
_______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel