recent commits
Ben Goodrich
+ /** Patch version for Stan package. */
+ const std::string PATCH_VERSION = "0";
when bin/stanc gets compiled, it isn't picking up the patch-level version number
8a67611678db66b845dd7335b2e60d1e4ade990c :
+* g++ 4.7 not compiling bin/stanc, but OK with models
I am not seeing any problem with g++-4.7 compiling stanc or anything else, except the somewhat random failures we are getting on some bugs models with all compilers.
8a67611678db66b845dd7335b2e60d1e4ade990c :
+* Download:
+ - latest code tarball (named as such)
+ (no git info, but everything else)
It is important to essential that make dist create a "tag" for the git HEAD when it creates the tarball for release. Otherwise, it does not get recorded in git's history when there was a release, and it is not possible to do something like
git checkout version_1.0.0
or to git bisect against 1.0.0 or any number of git things that accept a tag as an argument (which is pretty much everything).
It is possible to overwrite an existing tag with the -f option, so make dist could just do something like
git tag -f $(VERSION)
git commit -a -m "made auto-tag"
before taring everything up. But that generates a lot of noise commits when you are just trying to test that make dist is working properly. It might be better to make a script that calls make dist and uploads the tarball and documentation and whatnot and then that script can handle the git stuff at the beginning.
Ben
Bob Carpenter
On 4/19/12 6:23 PM, Ben Goodrich wrote:
> ab8e852d2b8de941e50435b52bde720dda7d027e :
> + /** Patch version for Stan package. */
> + const std::string PATCH_VERSION = "0";
>
> when bin/stanc gets compiled, it isn't picking up the patch-level version number
Thanks -- I need to put it in the actual
command and write it into the output.
> 8a67611678db66b845dd7335b2e60d1e4ade990c :
> +* g++ 4.7 not compiling bin/stanc, but OK with models
>
> I am not seeing any problem with g++-4.7 compiling stanc or anything else, except the somewhat random failures we are
> getting on some bugs models with all compilers.
I didn't follow. Does g++ 4.7 compile bin/stanc or not?
I was cleaning up a bunch of other stuff before
taking on the model failures. No idea what's up there
yet, but hopefully it won't be too hard to sort out.
> 8a67611678db66b845dd7335b2e60d1e4ade990c :
> +* Download:
> + - latest code tarball (named as such)
> + (no git info, but everything else)
>
> It is important to essential that make dist create a "tag" for the git HEAD when it creates the tarball for release.
> Otherwise, it does not get recorded in git's history when there was a release, and it is not possible to do something like
>
> git checkout version_1.0.0
>
> or to git bisect against 1.0.0 or any number of git things that accept a tag as an argument (which is pretty much
> everything).
>
> It is possible to overwrite an existing tag with the -f option, so make dist could just do something like
>
> git tag -f $(VERSION)
> git commit -a -m "made auto-tag"
>
> before taring everything up. But that generates a lot of noise commits when you are just trying to test that make dist
> is working properly.
I like your following suggestion better for exactly the reason
you state above. That's what we did with SVN for our product.
> It might be better to make a script that calls make dist and uploads the tarball and documentation
> and whatnot and then that script can handle the git stuff at the beginning.
The danger is that you forget to tag.
- Bob
Ben Goodrich
I didn't follow. Does g++ 4.7 compile bin/stanc or not?
Yes
Daniel Lee
I'm game for whatever makes sense. Part of me doesn't want a make target to automatically do this since the project is open source and curious contributors could end up tagging builds unintentionally. Scripting sounds good. We could also create a Jenkins project to automate as much as we can, including git tagging, tar-ing, etc.
The other option is to do it manually for the first few releases until we know all the steps involved and then script it.
Daniel
