[Feature Request] Add compiled beta's to Download area
(1) By skywalk on 2018-08-12 15:41:57 [link] [source]
If Fossil has an automated build system, it would help a lot to Download(http://www.fossil-scm.org/index.html/uv/download.html) the latest beta already compiled. :) When is the forum feature(v3.0 or v2.7) available?
Thanks for Fossil!
(2) By sean (jungleboogie) on 2018-08-12 20:40:22 in reply to 1 [link] [source]
This pretty much already exists, just doesn't have a 'beta' tag.
http://www.fossil-scm.org/fossil/download/
With your CI system, have your script download one of those options and compile from there.
(3) By Warren Young (wyoung) on 2018-08-13 04:38:56 in reply to 1 [link] [source]
When is the forum feature available?
Same answers as always:
When it's ready.
Sooner if you help.
Sooner if you stop meddling. ;)
Before Christmas. (We aren't saying which year.)
If it were me deciding when to release, I think there's at least another week or two of work before it'll be in a shippable state, and that's assuming other work doesn't get in the way. Like, you know, paying SQLite work.
I wish drh would use feature request tickets as a way to triage each version's requests, so we could gauge this better from the outside. In my own public Fossil-based projects, you know we're getting close to a release when all of the Immediate down through Medium priority bugs are closed and the Immediate and High priority feature requests are closed.
(Lower priority feature requests are for features we're putting off for future releases, and the Low priority for bugs is reserved for things we're mainly documenting without any intent to fix, like the BUGS section in a Unix man page.)
v3.0 or v2.7
If you got the "3.0" idea from one of my earlier posts, I didn't think that through very well when I suggested it might be a possibility. History suggests that we're not going to see "Fossil 3.0" until the next file format or wire format breaking change. So, we might conceivably never get out of Fossil 2.x, if the file and wire formats remain stable.
The most likely claimant for "Fossil 3.0" is Fossil-NG.
(4) By skywalk on 2018-08-13 18:29:46 in reply to 3 [link] [source]
Yeah, I was assuming the flow of this forum == old mail list <> tickets. Dumb question? When I reply, does the Markup style cookie not remember my preference? My posts don't always have proper newlines or hyperlinks, despite hitting 'Preview' for all 3 options?
(5) By Warren Young (wyoung) on 2018-08-13 19:12:12 in reply to 4 [source]
the Markup style cookie
I don't see any reference in the code to such a cookie.
The MIME type defaults to "text/x-fossil-wiki". You can override it by appending ?mimetype=text/x-markdown to the URLs, where the value is one of the azStyles values.
It looks like the PD() function will find the value in a cookie if it isn't found as a URL query parameter or as form data, but since there's no place in the code that saves the last-used MIME type as a cookie, what we're waiting on is for someone to write the code to do that, I guess.
Personally, I want it to default to Markdown. I can see from the code why it can't default to that for everyone: an artifact's data can refer to a blob without declaring its MIME type, which causes Fossil to render it as Fossil wiki in the case of wiki, ticket, or forum content. It only sets an explicit MIME type if you're asking it for some other markup language. To change the default now would be to invalidate all existing repo content that depends on this default, so all I'm asking for is a per-user default for new content.
I'd also like /login to become a user settings page, since it has gone well past being a login/logout page, and visiting it doesn't actually log you out, despite being hyperlinked to "Logout" in the default skin. The preferred markup language setting could be here as well.
My posts don't always have proper newlines or hyperlinks, despite hitting 'Preview' for all 3 options?
Once the markup language is properly set, it previews properly for me, and subsequent preview/edit/preview/post cycles do maintain the MIME type throughout. That happens because the calling form is passing mimetype via form data to the /forume2 handler, which then picks it up with the same PD() call I mentioned above.