1.4 release #219

Open
tkf opened this Issue Mar 23, 2013 · 9 comments

Comments

Projects
None yet
4 participants
Member

tkf commented Mar 23, 2013

Why not just release 1.4 as-is? Frankly speaking, I don't want to put too much effort for the current code base since I know @m2ym is going to do a major refactoring for 2.0. For example, I don't want to write docstring for functions that are going to disappear.

I categorize the issues that are in 1.4 milestone. To me, they are either not-urgent bug or problem that requires a major refactoring.

Need refactoring / discussion:

  • 148: it seems that auto-complete doesn't support the behavior like popup-menu*

    I wrote a patch for this #185 but that patch has a performance problem. Also isearch won't work. I think the popup value property has a conceptual issue. So, I suggest to not do this for 1.4.

  • 83: Abort autocomplete when less than ac-auto-start characters

    As I said in the thread, I suggest not to do this in 1.4.

Not urgent

I don't think these are urgent. We can do that later.

  • 167 / #149: Documentation

  • 133: semantic: Use yasnippet to complete a function with argument placeholders

  • 199: popup lines get wrapped in terminal mode with linum.el

    Isn't it popup.el's problem?

Trivial task:

  • #160: Add version number variable
Owner

m2ym commented Mar 24, 2013

Okay, let's release 1.4.

Tasks:

  1. Defer 1.4 issues to 1.5
  2. Easy test in some major environments
  3. Make 1.4 branch and v1.4.0 tag
  4. Make distribution package
  5. Distribute it at auto-complete.org
  6. Rewrite AutoComplete entry on EmacsWiki if necessary
  7. Announce?

Shougo commented Mar 24, 2013

Wow!

Member

tkf commented Mar 24, 2013

Defer 1.4 issues to 1.5

Why 1.5? If we go 1.5 instead of 2.0, I still don't want to touch code as 1.5 code will be irrelevant in 2.0. Many bugs will be (hopefully) easier to fix in the refactored code. Some bugs are just impossible to fix in the current code base. Rather than spending too much time for workaround of these problems, I suggest just throw away these tasks for 1.x and go directly to 2.0. I am not suggesting to ignore the bugs; we can fix it in 2.0, where code base is cleaner and easier to write unit test. For PR authors I feel very sorry but if we are likely to duplicate the work in 2.0, reviewing the PRs for code that is not used for near future is probably worse than ignoring the PRs because it just waste our time and their time. (If we are going to provide a compatible layer for the current source spec, reviewing PR for source enhancement makes sense, though.)

That said, I am +1 for 1.4 as current AC is stable for a while and it is not good to ask user to fetch code from the github repository. We can discuss about 1.5 vs 2.0 issue separately.

Distribute it at auto-complete.org

Why? Isn't mermalade (or ELPA, if you wish) fine? We don't encourage manual install, right?

Rewrite AutoComplete entry on EmacsWiki if necessary

I'd just add a following sentence at the top of the wiki page:

Information in this wiki may be old and unreliable. For correct up-to-date information, read the manual [link here]. If you have question or bug report, do it on the official bug tracker [link here] instead of doing it here. If you have some tips that could be useful for someone, please tell us on the issue tracker rather than writing it here (or better, send a PR to add that tips to the document!).

-- The Auto-Complete Development Team

yyr commented Mar 24, 2013

FWIW, I would agree with @tkf

Owner

m2ym commented Mar 31, 2013

@tkf Good suggestion. But a problem is that I have no much time to go forward 2.0...

Why? Isn't mermalade (or ELPA, if you wish) fine? We don't encourage manual install, right?

Sorry, just I wanted to say I wanted to make auto-complete.org be an official site that provides documentation and tarballs for manual install.

I'd just add a following sentence at the top of the wiki page:

Good, please.

Member

tkf commented Mar 31, 2013

The sentence for EmacsWiki does not make sense if we don't have an online document. Do we want to link to the current one, or to the new official site? Why not upload the current markdown-based document? The document is still good and we can use the same URL if we go to texinfo-based one.

Owner

m2ym commented Mar 31, 2013

I'll put the documentation at http://auto-complete.org/doc/. The bug tracker will be https://github.com/auto-complete/auto-complete/issues.

Member

tkf commented Mar 31, 2013

Great! I guess it's better to have doc/index.html also. I'll try the fix at some point if nobody does it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment