Issues are restored, and we've moved to Github!

Issues are restored, and we’re now on GitHub! Many thanks to @schwowsers and Steve Conklin!
Start thinking about a new name!


WOOHOO! Can you look into making it PortableApps compatible? That would drastically increase the potential client base, as well as letting users run it right from a USB/OneDrive/Dropbox folder if they wish.


@KeithFromCanada, please add PortableApps compatability to the issues list!

1 Like

name it ( CAD-Cuff ) computer aided design CAD and cuff as the entry gate of fashion design

1 Like

Ok, great! What is the recommended Git client? Could someone describe the recommended procedure for becoming a contributor? I mean, shall we fork the repository, or commit directly into the main repository?


Hey @yannlossouarn, I think the process remains the same as it did with Mercurial & Bitbucket.

  1. Create a GitHub account.
  2. Fork the project’s GitHub repository.
  3. Clone your fork to your local machine.
  4. Add the main project repo (upstream) to your clone as a remote repo. See here.
  5. Commit changes to your local repo.
  6. Pull from upstream and resolve any merge conflicts.
  7. Push changes to your fork on GitHub.
  8. Create a pull request.

I plan to update the wiki material for contributors to reflect the move and make things clearer. Also, I take it Steve is the new project maintainer, so if you’re reading this, welcome Steve!


@yannlossouarn, I see your are UI designer

Note Valentina UI uses actually Qt4 API and technology like Qt Designer which are deprecated in Qt5 and imho a mess (buggy, many limitations, etc.)

But move to QML is another story … (Tape is less challenging)

1 Like

Let’s have a new thread for building with Qt.

How to build with Qt

1 Like

Let’s have a new thread for discussing working with the Github repo

How to work with Github code

1 Like

Is there any easy way to “pull” or print a complete copy of the supporting text and information for any specific issue documented in the repository? I can use the sledge hammer approach and make lots of screenshots. I was hoping there is something easier that I just don’t know. I am preparing for a long stretch with no internet

1 Like

thanks for the info. I have a question (probably for Steve but you might have the answer). is it reasonable for me to do another fork of the valentina-team/vpo2 repository just before i leave next week. My intent would be to capture the most current committed items including source and issues

Hey many people create multiple forks of a given project. This is not unusual. Hope everything is good with you, I’m way busy this week.

I would assume you can make as many remote forks as you want, as well as any number of local forks?

In regards to forks and commits - just to make sure I got it correct… I made a fork of the original-> develop branch and then made a local clone, then updated to most recent commits. Created a new local branch “fixes”… made fixes and built to check the fixes.

So now the question is… do I make the commits to the the fixes branch, merge to develope, then push to fork -> develope, then make a pull request to the original? Or, do I create a fixes branch on the fork, commit the changes to the local -> fixes, the push the changes to the fork -> fixes… merge fixes to develop on fork and local… then make a pull request?

In other words, do I want the local and remote fork to mirror each other? And specifically where should any pull requests be made from?

Hi @Douglas, Yes, you understand the workflow.

One thing though.

You merge your local fixes branch to your local develop branch. Then in Qt, do the steps to Build All then run and test it for how to break it. If it seems reasonably okay, push to your remote firk and make a pull request.

I think you should have a fixes branch on your fork as well, not only your local.

This way other people could take a look at your changes if you need help. Theoretically, someone could even contribute.

Also your work is saved on the repo and not only on your local machine. It might come in handy if you lose your data on your local machine for some reason.

When you’re done then you can merge your fixes branch to your develop, test everything like Slspencer said (make sure to also update your develop branch on a regular basis and that it’s up to date before the pull request) and then make a pull request to the original repo.


That’s kinda of what I was thinking.

That’s a given to me… I’m a stickler for details and would rather get it right the first time and not have to fix it later.

Is it best to update develop then merge to develop OR merge to develop then update develop?

Anybody good at making flow charts? This would be super for the wiki.

1 Like