Closed ghost closed 9 years ago
I'm still traveling, but am trying to get things with lfetool to a stable state. This will probably mean fixing the current lfetool to explicitly use 0.8.0. [See footnote 1]
Here's what needs to be done:
I will create (or update) tickets for these.
Footnotes
[1] Thanks to the way that rebar handles (or doesn't handle) multiple versions of the same project, to support 0.9.0, I will need to update all projects that lfetool uses as dependencies when it creates skeleton projects.
[2] This is necessary to support older releases of lfetool that are still in use, which depend upon the master branch being where it currently is
Oh, I meant to also add the work-around until the bug is fixed:
cd
into the new project and update rebar.config
's entry for LFE:
.*
to "0.8.0"
"master"
to {tag, "v0.8"}
rm -rf deps
make compile
I've created the following related tickets for these issues:
I'm going to rename this ticket from "LFE master branch has switched to 0.9.0" to what needs to be done, i.e., "Update lfetool to use LFE 0.9.0"
@oubiwann up on this, any updates / ETAs ?
The lfetool dev-1 branch is using LFE v0.9.0.
Once the 1.4 milestone is complete, this (dev-1) will get merged to stable. No ETA on completing the milestone right now, but I myself have been using lfe from the dev-1 branch ...
@pigmej I'm going to try to release 0.9.0 support today, if I can get all the necessary tasks accomplished. Outstanding issues I will move to a new 1.5 milestone.
1.5 will support LFE v0.10.0, which I also hope to get out very soon.
Is it possible for lfetool to get the latest commit on the master branch by default, or perhaps as an option. Commits on the master branch are "release worthy" even if they don't have a version number. All experimenting is doen on develop and other branches. It might be interesting to also have an option which gets the latest commit on the develop branch.
Note I don't know if this is possible,
Robert
On 4 January 2015 at 21:18, Duncan McGreggor notifications@github.com wrote:
@pigmej https://github.com/pigmej I'm going to try to release 0.9.0 support today, if I can get all the necessary tasks accomplished. Outstanding issues I will move to a new 1.5 milestone.
1.5 will support LFE v0.10.0, which I also hope to get out very soon.
— Reply to this email directly or view it on GitHub https://github.com/lfe/lfetool/issues/111#issuecomment-68647184.
I've just released lfetool 1.4.0 which has LFE 0.9.0 support. Am getting ready to set up 1.5.0 milestone which will support 0.10.0-dev LFE.
On Sun, Jan 4, 2015 at 3:28 PM, Robert Virding notifications@github.com wrote:
Is it possible for lfetool to get the latest commit on the master branch by default,
Using non-versioned repos by default can get a bit messy, strange, and broken at times. It would work for new projects, but say a project is created today that uses all the latest. Then next year, after LFE and other libraries have grown in features, have breaking changes with old code, etc., when that project updates, it's now broken, and in possibly unexpected and hard-to-track-down ways. Not only was I running into this issue, but others in the LFE community had started reporting bugs against LFE, lfetool, and other libraries that weren't actually bugs -- they were just running into breaking changes getting pulled into their projects without being aware of it.
Explicit version numbers is the fix for this.
However, as you and other have noticed, this locks projects into very specific versions, and one has to start updating rebar.config files in the deps directory to get any level of flexibility. That's what this ticket is for (and is complaining about):
Working on the LFE-in-Docker project was absolutely awful for that one reason (everything being locked to specific versions). The "easy" way out in that case was "just" to bundle a deps dir.
or perhaps as an option.
That would definitely be better. There are ways we might be able to do this in lfetool ... but it's really a problem at rebar's level.
If they fixed this issue, much of the pain would go away:
Then users could just update their project rebar.config to the versions they wanted, and would never have to do the awful hackery/deps bundling that I had to do for the Docker project.
But, that's not fixed, so we have to work with what we've got :-/
Commits on the master branch are "release worthy" even if they don't have a version number. All experimenting is doen on develop and other branches. It might be interesting to also have an option which gets the latest commit on the develop branch.
Note I don't know if this is possible,
There are a couple of things that come to mind ... but I think we'd have to:
I'm not sure if this can be done within the confines of rebar's current feature set. We may have to implement this with bash, LFE, or Erlang.
I'll ponder it some more...
I am going to close this issue (since 0.9.0 support is now released); let's continue the conversation about fixing the version-pinning problem in issue #135, "Working with versioned deps can be a nightmare".
The LFE branch on github.com/rvirding/lfe has switched to 0.9.0 and creating a new project with
lfetool new service blah
fails on the dependency check forltest
("0.8.0" expected, "0.9.0" found).