-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposed guidelines on F# packages and projects #13
Conversation
Thanks, fixed |
Regarding 2. in the header (don't pollute FSharp.* namespace) - this goal seems to contradict, at least partly, the second naming guideline. Would it make more sense to propose an "experimental" top level namespace, and suggest switching to FSharp.* at a point in time when the library meets the goals of 1 &4? It'd be a breaking change, but so is moving from FSharp...Experimental to FSharp.., which is recommended later. My concern here is, over time, having a lot of "FSharp..Experimental.*" libraries that never leave experimental stage, effectively "polluting" FSharp.. Regarding the 2nd level namespace guidelines:
|
Re 1 - my impression is that using "experimental.FSharp.*" or indeed any Experimental tag greatly decreases the level of early engagement, and people just don't seem to like doing it. We had quite a lot of feedback like that when we last suggested "Experimental". I think incubating FSharp.* is probably OK if used in combination with other mechanisms such as
|
Re 2nd level namespace guidelines - yes, agreed on both points (though there maybe things that really, really fit in core, e.g. if incubating a compiler feature that needs compiler helperrs). Could you send a PR with a list of 2nd level namespaces add? I think including it here is right. |
Perhaps then there should be some guideline around the incubation/beta/pre-release phase and documentation? Something like: Guideline: Clearly label project status prior to releaseProjects, packages and tools using the FSharp.* top level namespace should clearly and prominently label their status in all documentation during the project's early phases of development. Projects should use version numbers below 1.0 to denote pre-release status, and clearly label their status as "Alpha" when the project is still lacking features or functionality required for widespread usage, and "Beta" prior to adequate usage and testing to be considered a mature package. |
@ReedCopsey - Yes, agreed, could you add that? thx |
as per discussion in #13
@dsyme I believe that PR should address both issues. |
Added language as requested by dsyme
I like this proposal. I also agree that the How should we hide projects that are no longer active? Once they are on NuGet I'm not sure we can do better than emailing the author. |
Proposed guidelines on F# packages and projects
As an alternative to The same approach uses // cc @forki @fsgit @ReedCopsey |
Can you create a PR with that as a recommendation? |
I jotted down some notes about core v. non-core project management here: #19 |
This is a set of proposed project and pakage guidelines, including naming, software engineering and general advice. Discussion about the guidelines can be made in this github issue and by notes on the text. I will also broaden the discussion to the F# open source list after a few initial iterations.
The draft is visible here: http://dsyme.github.io/2014/09/19/fsharp-libraries.html
Specific comments on this thread, general disucssion here: #14