Open zaxebo1 opened 9 years ago
I am occasionally came across this question; I guess I know the answer — Pandoc development stalled.
Ones who would want a converter have to look at forks or forking.
It seems not that much stalled. pandoc 1.15.1 (released on 15 Oct 2015) has lots of features implemented, esp. useful for me regarding enhancements in docx support and new ODT reader support.
Now, scholdoc as of now will have not support of ODT reader. We will have to wait for scholdoc's rebasing to pandoc 15 Oct 2015 , so that we can get scholdoc features and the new pandoc 1.15.1 features both.
If rather than maintaning scholdoc as a fork, if scholdoc was a new extension to pandoc/a new reader to pandoc/a new writer to pandoc THEN scholdoc would have benifited from these new features of pandoc 1.15.1 from day one automatically.
@zaxebo1 I argued with Pandoc's maintainer much, one of discussions I linked in the previous message. There a bunch of bugs in pandoc, that will never be fixed. More over, I've seen a patch that wasn't applied for two years, and it won't ever be merged.
So, perhaps the developer sometimes adds some things, but if you look at the last messages of the previously linked discussion, you will see that Pandoc wouldn't ever grow up to be a good converter. Pandoc definitely should be forked.
hmm.. okk. I am convinced for the necessity of the fork. ( i was not raising any sharp questions on the fork , i was just trying to humbly understand the situation) Thanks for giving us scholdoc
Now, just a curious question regarding fork maintenance: " if as an academic person , (say) i am convinced and chose to use scholdoc, and then now i want latest features of pandoc 1.15.1 (15 Oct 2015 release) too into it , then what strategy should i be expected to follow? Say, approximately after how many days the pandoc latest release change is currently merged with scholdoc fork? or, the strategy is that this scholdoc fork will not rebase again with new releases of pandoc"
When you make and maintain it as fork of pandoc, then there is always a splitted effort . Why not make it as an extension
for example: currently
currently already markdown_phpextra ,markdown_github are implemented
NOW, in the same way, the scholarlydoc extension can be: pandoc -f +markdown_scholdoc ...... Hence, it will be not be a fork as two separate project - pandoc and scholdoc, but rather markdown_scholdoc is just extension flag of markdown of pandoc
So,It will co-exist with main codebase of pandoc, without always catching up with the bugs fixed there in the docx generation.