A usual flow of a project (in my field) commonly looks like this:

having a result -> (1) writing a paper (with all the proofs) -> (2) making a conference version -> (3) uploading a full version to eprint -> (4) journal version

Usually, (2) is a shorter version of (1); and (3) is almost the same as (1) up to some changes that came up during the process of making (2); Yet, the work on (2) and (3) happens almost at the same time.

The question is how to deal with maintaining both versions (full + short) of the same paper.

So far I have been keeping two separate "papers", but this solutions has its problems: if you make a change to one (say, fixing a typo), you need to remember making the same change in the other one (which you usually forget).

What is the best strategy?

  • 3
    I'd like to hear of a solution to this: I have yet to find one. Having said that, one trick is to delay creating the "conference" version to as late as possible in the writing process. – Suresh Dec 28 '12 at 21:20
  • 1
    If someone had the experience of keeping a single file, and using latex's \if command to make two versions out of it -- I'd really like to hear about that as well! – Ran G. Dec 29 '12 at 7:39
  • 1
    Ugh. I've used that in the past. it's terrible to maintain and debug. – Suresh Dec 29 '12 at 8:01
  • @Suresh would you like to expand a bit? what are the main problems, etc? – Ran G. Dec 29 '12 at 18:39
  • 2
    I have tried the single file approach (using all kinds of Latex tricks), and it is indeed a pain. In practice, whenever you make a change, you will have to recompile all possible versions of your document and check that all of them look good; otherwise you easily break one version accidentally. Another problem is that many edits are also related to the layout, not content (e.g., fine-tuning the placement of figures, page breaks, line breaks, etc. for the camera-ready version), and trying to produce a single Latex document with all version-specific layout tweaks results in messy & tricky code. – Jukka Suomela Dec 29 '12 at 23:24

You can change your workflow slightly:

  1. Write a paper with full proofs, polish it, and upload to arxiv.

  2. Prepare the conference version (fairly late). You will use version 1 as your starting point, but you can edit it freely. You can remove proofs and refer to the arxiv version. You can polish the story, introduction, etc. You may spot typos in the arxiv version, but do not worry about those too much. There is no need to revise the arxiv version yet if the typos are minor.

  3. Prepare the journal version. The key thing is that you will use version 2 as the starting point, not version 1. Of course you will now copy-and-paste the full proofs from version 1, but the rest of the text comes from the conference version. Therefore the main matter has already automatically gone through all the revisions that were related to the preparation of the conference submission(s), addressing conference reviews, preparing the camera-ready conference paper, etc.

Now you can simply revise your arxiv submission by replacing it with the journal version, whenever the journal version is ready.

If you follow this approach, there is never need to maintain parallel versions. You will never need to worry about updating version x when you fix typos in version y. People interested in your work can read the first arxiv version early, and your final arxiv version is as well polished as the journal version.

Note that you can start phase 3 as soon as you have prepared the final camera-ready version of the conference paper. When the conference version finally appears, you can already have a preliminary draft of the journal version written, and you can use it to revise your arxiv submission if it seems to be a good idea.


I would use git with branches and selective merging. You can selectively merge your typo fixes and stuff between one branch and the other, in whichever direction you choose.

  • how does it deal with moving proofs/sections to appendices etc? – Ran G. Dec 29 '12 at 3:53
  • You'd make sure to separately commit such moves, so you could reverse them later on. – Suresh Dec 29 '12 at 5:09
  • 1
    @RanG. move them in one branch. commit change. Just don't merge that change to the other branch. – mankoff Dec 29 '12 at 5:20
  • thanks, I'll read more about branching (hopefully the same goes with SVN) – Ran G. Dec 29 '12 at 7:36
  • 1
    I would not try to do this with svn; use git (or other modern version control systems). I think this approach might work if you have a full control of everything, but if you have any coauthors (especially senior coauthors), someone will definitely mess it up, sooner or later. – Jukka Suomela Dec 29 '12 at 13:47

If you are using latex. I use following approach. I define three variables. ArticleTypeAll , ArticleTypeJournal and ArticleTypeConference . I use ArticleTypeAll for parts which is same for all parts (Conference and Journal). In my example authors information. I use ArticleTypeJournal for only journal part. For example introduction to journal may be different than conference one. Same goes for ArticleTypeConference.

I split every part to different latex file to easily version control and compare them. If command allow me to conditionally include files. Here I use input instead of include since this is an article. I set variables as.

  • ArticleTypeAll = true
  • ArticleTypeJournal = true
  • ArticleTypeConference = false
\author{Atilla Ozgur}
\title{Conference Journal Together}



    this place is included in all

    this place is included in journal article only

    this place is included in Conference article only





Output of this document like below.

this place is included in all
this place is included in journal article only

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.